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

Joshua Gargus schwa at fastmail.us
Fri Aug 15 07:11:21 UTC 2008

(Wishing myself more success with writing this email before sending it :-) )

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.
Not that it's immediately relevant, but keep in mind that we'll 
eventually want to be able to share behavior between images.  Possibly 
the most important thing is how much happier this will make the L2 
caches on future multi-core chips.
> Now, why i think its more convenient than having separate images?
If you had to pick between one or the other, I can see how your argument 
makes sense.  However, I don't see why you can't trivially have both.  
Furthermore, there are use-cases where the ability to load an image from 
disk (or from the network) might be useful.  More on both of these 
points below.
> 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.
This seems like an unfair comparison.  A better comparison would be 
comparing your method to running an image once it has already been 
loaded from a file (since, of course, you can store an image as a a 
ByteArray in memory just as easily as you can store your 
> 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.
The technical details of your approach sound good to me (without having 
thought deeply enough to provide truly constructive criticism).  However...

My main concern is that your argument against separate images is 
disingenuous.  They won't be slower if you store them as ByteArrays 
within the main image.  In fact, I believe that the opposite would be 
true; don't you agree?  From a performance standpoint, it seems like 
separate images are the better option.

Separate images allow (security implementations aside) nifty things like 
mobile code... I can download an image from a server or a P2P network 
and run it in my image.  I don't yet know what I would do with this 
ability, but as we ge more experience with the object-capability 
security model (hello Newspeak!) I'm sure that there will be no shortage 
of good ideas.

Of course, these separate images need to be built somehow, and it seems 
to me that this is where your ideas fit in (for development more than 


More information about the Squeak-dev mailing list