Contextualizing the VM environment?
piumarta at speakeasy.net
Thu Apr 13 20:53:31 UTC 2006
> What would happen if we changed the VM so that we fetch the
> specialObjects array from the active process? In other words, each
> process could potentially carry its own VM environment which
> effectively describes its own variant of the VM state. With the
> effect being that different processes could potentially have
> different versions of class SmallInteger etc.
> The basic question here is: Can you guys see any reason why this
> *wouldn't* work? Is there anything I'm overlooking? Any situations
> in which this would cause problems while (say) interrupt processing
> or somesuch?
The spirit of this I like a lot.
A few things off the top of my head... The VM caches some objects
for speed (nil, true, false) that you'd have to reload at process
switch. You still wouldn't have complete isolation of the VM
internals between processes. They'd all have to agree on the
processor scheduler (or keep activeProcess apart from it); the
formats of the splObj classes couldn't change too much (changes in
splObjs do not affect the assumptions in the way primitive access
fixed fields -- or you could make the primitive table process-local
too ;-); compact classes would have to be the same (or non-
overlapping) for any pair of processes that share instances;
semaphores would have to be reloaded at process switch unless you
admit the possibility of some processes hijacking interrupts, low
space, etc. from the installed handlers.
Of course, the correct solution is to get rid of the VM entirely.
(By assuming the splObjs subsume the interesting aspects of VM
internals and then making them process-local, you are essentially
trying to pull most of the VM implementation up into userland with
per-process granularity on customisation of its behaviour.)
More information about the Vm-dev