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

Joshua Gargus schwa at fastmail.us
Fri Aug 15 06:08:33 UTC 2008


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.
>
>   




More information about the Squeak-dev mailing list