[gambit-list] Gambit linking

Dimitris Vyzovitis vyzo at hackzen.org
Tue Nov 5 23:58:59 EST 2013

Is it really necessary?

Why not handle module loading in the primordial thread, which would be the
first boot thread for global data structures and then the boot thread per
VM for concurrent initialization.

The programmer can then load modules explicitly per VM. All that is needed
is an API to select the target VM.

-- vyzo

PS: a performance related suggestion: use __thread for TLS with gcc/glibc
if you are planning a 1-1 VM to OS thread mapping (instead of pthread tls).
 On Nov 5, 2013 9:11 AM, "Marc Feeley" <feeley at iro.umontreal.ca> wrote:

> Currently a Gambit executable program is a list of modules, with the
> "main" program as the last module.  During the setup phase (function
> ___setup) these modules are initialized sequentially (as though they were
> "load"ed in turn).  For example, the Gambit interpreter, gsi, consists of
> these modules ("_kernel" "_system" "_num" "_std" "_eval" "_io" "_nonstd"
> "_thread" "_repl" "_gsilib" "_gsi").  The module "_gsi" contains the code
> which starts the REPL.
> This is fine in the context of a single Gambit VM instance per OS process.
>  However, for the upcoming multithreaded Gambit, I want to support multiple
> VM instances per OS process, so the current linking model is not ideal.  If
> the current linking model isn't changed, each VM instance will have to run
> the same program (requiring all VMs to initialize all the modules of the
> program), and the programmer will have to create custom logic in the "main"
> program to select the appropriate VM behaviour.  This is clumsy.
> So I'm considering changing the linker data structures to record module
> dependencies.  Something like "before initializing module A, it is
> necessary to initialize modules B, C, and D".  An executable program would
> thus be a set of modules with dependencies, and the name of the main
> module.  The setup phase would do a depth first traversal of the dependency
> graph starting at the main module.
> This would enable a few interesting features:
> 1) Allow the instantiation of a VM with a "main" module different from the
> other VMs, e.g. (start-new-vm "other-main").
> 2) Lazy initialization of modules (only the modules actually relevant to
> the main program need to be initialized).
> 3) Multiple modules could be bundled this way in a single executable
> program.  The "load" procedure could be changed to lookup modules in the
> bundled set before going out to the file system to dynamically load a .o1
> file.  This would simplify the installation of multi-module applications
> and give better startup performance.
> Note that for this to work, it will be necessary for the compiler to
> record module dependencies with each module and to output these
> dependencies in the linker data structures.  A new special form, such as
> (depends-on <module>), will have to be added so that the programmer can
> express initialization dependencies in the source code.  For consistency,
> the interpreter will also have to support this form.
> Before going forward with this change, I would like to have some feedback.
>  Do you see problems with this or suggestions?
> Marc
> _______________________________________________
> Gambit-list mailing list
> Gambit-list at iro.umontreal.ca
> https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.iro.umontreal.ca/pipermail/gambit-list/attachments/20131105/a07b9926/attachment.htm>

More information about the Gambit-list mailing list