Contextualizing the VM environment?

[Ian Piumarta]

Hi Andreas,

> 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.)

Cheers,
Ian