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
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; tim@rowledge.org; http://www.rowledge.org/tim Breakthrough: It finally booted on the first try.
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 & 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@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
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
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.h...) 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
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
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
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
vm-dev@lists.squeakfoundation.org
-
Andreas Raab -
Colin Putney -
Craig Latta -
Ian Piumarta -
Klaus D. Witzel -
tim Rowledge