Igor Stasenko wrote:
> Well, for instance, lets consider following use case:
> suppose i ran some code in main image, which marked all objects which
> this code used.
> Then i can create new object memory, containing this memory and spawn
> zillion of parallel running interpreters.
> It is good, because you don't have to deal with files and preparing
> images. A marked code memory footprint can be really small in this
> way, which you can never achieve using 'hard' way.

Let me correct you. Not only can the "hard" way achieve it, it is in 
fact the *only* way by which this can be done in general. You're 
probably not realizing this but what you describe above is literally how 
Croquet replication works. When a participant joins, we create a 
snapshot of the current space and we do this by creating an image 
segment for all the objects in this space. The only reason we can do 
this is because we *know* (by having built it the hard way) which 
objects are in what island. Without that knowledge originating from 
islands and future sends it would be completely impossible to extract a 
self-contained, consistent set of objects.

> Yes, as Klaus noticed, there of course the difference between code
> which runned and code which potentially can be run, if you provide
> different input to it.
> But this, i think, up to ones who using this, not me :)

True. I just happen to think that the mechanism is fundamentally flawed 
and cannot possibly work the way in which people naively think it ought 
to work. And by now we do have quite some experience in building actual 
production systems that use such mechanisms and that's exactly where my 
opposition comes from. Note that it's always easy to come up with 
trivial little examples where things will work all right. It's even 
possible to come up with situations where it works "most" of the time 
(Morphic projects are one such example). But *all* the time? No way 
unless you're doing it the hard way because it is the only case in which 
you can assert the properties that you need.

> Oh, and maybe then, if you strongly opposing this to be as part of VM,
> then what about doing this at language side? What if let users develop
> own ways how to create custom object memory, and make this as simple
> as:
> 
> array := MyStripper scanMemoryForUsefulObjects.
> HydraVM spawnInterpreterWithMemory: array.
> 
> .. so this will require a single change in HydraVM, just a simple primitive :)

We have this already. It's called an image segment.

Cheers,
   - Andreas