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