Contextualizing the VM environment?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Contextualizing the VM environment?

Andreas.Raab
Hi Guys -

While looking at some of the meta aspects of Croquet I found that one of
the most problematic issues with code replication is that we really
can't separate code bases entirely. That's because there are various
references to "special" classes or objects that the VM knows about and
uses in very intricate ways (like contexts, compact classes etc).

One thought I had was that (unless I'm horribly mistaken) all of these
special objects originate in the specialObjectsArray - as a matter of
fact it seems that the splObjects are really *the* root of the system
(besides the active context).

So I had this crazy thought that I'd like some comments on: 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?

Cheers,
   - Andreas
Reply | Threaded
Open this post in threaded view
|

Re: Contextualizing the VM environment?

timrowledge
You might need to check on GC issues. Without examining things  
carefully I would hazard a guess there is some chance of needing to  
have a specialArrayOfSpecialObjectArrays to give a single point for  
GC to handle them all. It might simply fall out in the wash of course.

You'd also need a good  way to get the active process cheaply and one  
that doesn't fall over if someone changes the context chain during  
coroutining or exception handling etc. Classic failure point of  
context caching without sufficient thought.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Breakthrough: It finally booted on the first try.


Reply | Threaded
Open this post in threaded view
|

Re: Contextualizing the VM environment?

Ian Piumarta
In reply to this post by Andreas.Raab
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

Reply | Threaded
Open this post in threaded view
|

Re: Contextualizing the VM environment?

Klaus D. Witzel
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 <[hidden email]>
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
>

Reply | Threaded
Open this post in threaded view
|

Re: Contextualizing the VM environment?

Colin Putney
In reply to this post by Ian Piumarta

On Apr 13, 2006, at 4:53 PM, Ian Piumarta 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.)

Hi Andreas,

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?

Colin
Reply | Threaded
Open this post in threaded view
|

Re: Contextualizing the VM environment?

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

Cheers,
   - Andreas
Reply | Threaded
Open this post in threaded view
|

Re: Contextualizing the VM environment?

Andreas.Raab
In reply to this post by Ian Piumarta
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
Reply | Threaded
Open this post in threaded view
|

Re: Contextualizing the VM environment?

Colin Putney
In reply to this post by Andreas.Raab

On Apr 14, 2006, at 1:04 PM, Andreas Raab wrote:

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

Ok, I see. The two ideas do seem complementary though.

Colin
Reply | Threaded
Open this post in threaded view
|

Re: Contextualizing the VM environment?

ccrraaiigg

Hi all--

        (Colin writes to Andreas:)

 > How does this idea differ from what you proposed after Craig posted
 > his 1337 image a while back?

        By the way, I put my notes about that at http://netjam.org/spoon/smallest/.


-C

--
Craig Latta
improvisational musical informaticist
www.netjam.org
Smalltalkers do: [:it | All with: Class, (And love: it)]