Contextualizing the VM environment?

Klaus D. Witzel klaus.witzel at cobss.com
Fri Apr 14 13:37:08 UTC 2006


Hi Andreas & Ian,

doesn't separating the interface functions (I/O, display, other) result in
(shudder!) an appartment like environment: every such interface function
can/will be process-local and passing args (shudder!!) has to be done by
means of marshalling.

Besides of that: good idea, I like it. Would allow running several
versions of the same thing in parallel.

/Klaus

On Thu, 13 Apr 2006 22:53:31 +0200, Ian Piumarta <piumarta at speakeasy.net>
wrote:

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




More information about the Vm-dev mailing list