On 22/02/2008, Andreas Raab <andreas.raab at gmx.de> wrote:
> Igor Stasenko wrote:
>  > Well, there is people who wish to see such capabilities, and if Spoon
>  > features orthogonal to your approach, then why not include them?
>
>
> Because there is cost associated with it. Probably some runtime cost
>  (which I haven't measured) but definitely cost in terms of added
>  complexity in the VM.
>
>
>  > In this case both camps will feel suited with new VM and can use it in
>  > one way or another.
>
>
> My problem with this is that I cannot see any situation in which someone
>  would really want to rely on that mechanism. It seems to me that the
>  approach is (as you said in an earlier email) a way to create smaller
>  images "without much effort". I'm interested in the *hard* way of doing
>  this (i.e., by going in and refactoring and removing things manually)
>  because I think this is the only way in which it can be done in practice.
>

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.

This can look as simple as following:

copies := HydraVM markMemoryWhileDoing: [ .... code...  ] thenSpawnCopies: 100.

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 :)

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 :)

>  But be that as it may - the real question is this: Let's assume we have
>  a tiny kernel image that is about 100k in size and that we can build up
>  from. What good is the mechanism at this point? It seems to me that it
>  is only useful to get to a small image but once this is achieved it's
>  basically obsolete. And I'm definitely not in favor to modify the VM for
>  something that will only have a very short window of usefulness.
>




-- 
Best regards,
Igor Stasenko AKA sig.