[gambit-list] Gambit linking

Mikael mikael.rcv at gmail.com
Tue Nov 5 15:30:28 EST 2013


What is the context here:

That all the GVM:s share one and the same heap so objects are
inter-accessible between GVM:s, but, while the set of globals in existence
is shared between GVM:s too, each GVM has a unique variable slot for each
global?

So then, this context is what is calling for this new dependency
abstraction?



Then to understand you further, please correct my following attempt at
filling out some blanks:

Will each module be required to be initialized once per GVM (so that the
module's globals in the GVM will refer properly to the module's procedures
etc. on the heap) with the exception of modules containing bootstrap code
(such as, launching the REPL), and therefore the dependency information
will also contain for each module an instruction about if it is intended to
be initialized in one or every GVM?

When you create a new GVM, will its global variables slots be empty or a
copy of those of the "parent" GVM?




2013/11/5 Marc Feeley <feeley at iro.umontreal.ca>

> 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/1c64a27e/attachment.htm>


More information about the Gambit-list mailing list