Oops, that last send was just a leeeeetle bit premature.  The real 
response will be along shortly.

Sheepishly,
Josh


Joshua Gargus wrote:
> Igor Stasenko wrote:
>> Hi folks,
>>
>> soon Hydra will provide a support to instantiate new interpreter
>> instance from current object memory, e.g. not based on images which
>> residing on file system.
>>
>> The main focus for this feature is to create a tiny images, with
>> limited behavior for off-loading processing from main interpreter to
>> separate worker interpreter.
>> Since Hydra already has mechanisms to transfer data between
>> interpreters, the need in initially packing new image(s) with data is
>> minimal.
>> The most important (and interesting) IMO is to define and transfer a
>> behavior (classes & their methods) which is minimal for solving some
>> problem in its domain.
>>
>> Now, why i think its more convenient than having separate images?
>> First it is easier to support and distribute: you having a single
>> 'bloated' main image which carrying all necessary code & data and
>> don't need to build a bunch of small images and manage them in
>> distribution.
>>
>> Firing new interpreter instance through copying data from base heap to
>> new heap could be even faster than reading & running image from file,
>> because no disk i/o and all operations performed in memory.
>>
>> A primitive, which doing copy & run takes two arguments: an array of
>> object refs to be cloned into new heap and array of stubs in a form of
>> pairs (oop + index of oop in first array which will replace reference
>> to original oop).
>> Before doing anything, the primitive check if given arguments forming
>> a closed object memory graph e.g there is no references outside of it.
>>
>> These two arrays can be pre-generated and sit in base image, so you
>> may have different sets of precalculated graphs for different needs
>> and then simply spawn new interpreter(s) at system startup.
>> Also, as far as you controlling development & distribution cycle, you
>> can keep such arrays within image and recalculate them when it needs
>> to.
>> And you can always include any mechanisms for error handling in
>> mini-images which could tell if anything goes wrong (like handling
>> unknown messages, catching bugs etc).
>>
>> Also, i'm looking forward for integration with Spoon main feature -
>> behavior imprinting, when consumer image asks provider image to
>> deliver behavior required to run some code.
>>
>>   
>
>