Contextualizing the VM environment?

[Andreas Raab]

Ian Piumarta wrote:
> 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.

All of these are pretty acceptable tradeoffs. In reality, my main 
interest is in getting a "reasonable" separation, not necessarily a 
"total" separation. What I'd like to be able to do is, for example, 
allow people in one Croquet island to manipulate class SmallInteger and 
have these changes be visible only on their local island. For most 
classes this is trivial (since you can just use multiple versions) but 
for some of them (like SmallInteger) this is hard since the VM knows a 
lot about it.

About nil, true, false: Good points. I need to think about it. 
ProcessorScheduler, however, seems simple to deal with. All you'd need 
to support multiple processors is to inject one process with the "new" 
environment which then then just assigns Processor ;-) Not that I'd do 
that casually but it seems pretty straighforward.

Cheers,
   - Andreas