Contextualizing the VM environment?

> 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?

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

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

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

> Colin Putney wrote:
>> I have a question along the lines of Ian's observation above. How  
>> does this idea differ from what you proposed after Craig posted  
>> his 1337 image a while back? (http://lists.squeakfoundation.org/ 
>> pipermail/squeak-dev/2006-January/099832.html) In both cases,  
>> you're talking about, essentially, a VM instance per Process. Is  
>> this another approach to the same idea, or is there a key  
>> difference that I'm missing?
>
> The key difference is that a contextualized VM environment would  
> allow for different versions of, say, class SmallInteger and any of  
> the other "special" classes. The 1337 image doesn't address this  
> (at least this hasn't been mentioned); the above discussion is  
> about factoring out process management which is a different beast.