[squeak-dev] A few more arguments to instantiating object memory based on another one

Igor Stasenko siguctua at gmail.com
Fri Aug 15 03:19:44 UTC 2008


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.

-- 
Best regards,
Igor Stasenko AKA sig.



More information about the Squeak-dev mailing list