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@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:
- Allow the instantiation of a VM with a "main" module different from the
other VMs, e.g. (start-new-vm "other-main").
- Lazy initialization of modules (only the modules actually relevant to
the main program need to be initialized).
- 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@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list