Hi Michael,

Interesting you should mention this particular topic. Just today I wrote a
message to David Reed which discussed (besides other things) a potential use
of "time-based submemories" quite similar to what you are describing.

I need to give a bit of background about the TeaTime model in Croquet for
this. Croquet includes a fully time based model of execution, e.g., when you
want to get work done you not only say WHAT to do but also WHEN it should be
completed. The "when" part is captured by a TeaTime which has some
"workload" associated with it. Each TeaTime has three states - "undecided",
"committed", or "aborted". When it is created it starts out as undecided. If
any particular workload associated with it completes before this TeaTime
expires it turns into "committed". If it doesn't complete (or else is
explicitly aborted) it becomes "aborted". One of the key properties of an
aborted TeaTime is that it leaves no "traces behind", e.g., all of the
changes which may have happened within objects will be undone.

As you may imagine, having to track all the potential modifications
manually, will be pretty inefficient (although we're going to start out that
way in order to be able to understand the implications better). That made me
think about making use of memory generations to capture all modifications
done for all objects while some TeaTime is "completing" (e.g., delivering
its workload) and then - in an atomic operation - be able to commit or abort
all the changes at once; essentially retiring all of the modifications of
simply have them reverted.

If such a scheme works (which I have absolutely no idea about - much of it
depends on "typical" properties of the workload associated with each
TeaTime, its typical orderings as well as dependencies) you should get a
really nice generational partitioning of your objects. How well this
translates into replicating object clusters I am not sure but keep in mind
that Croquet is a fully distributed system and as such my hope is that it
may work *extremely* well in the TeaTime-based environment that Croquet
provides.

Just something to think about ;-)

Cheers,
  - Andreas

> -----Original Message-----
> From: squeak-dev-bounces at lists.squeakfoundation.org 
> [mailto:squeak-dev-bounces at lists.squeakfoundation.org] On 
> Behalf Of Michael van der Gulik
> Sent: Monday, July 07, 2003 11:27 PM
> To: squeak-dev at lists.squeakfoundation.org
> Subject: submemories and grouping objects (was: Re: Islands 
> up and running)
> 
> 
> Mmm.. yummy. I'll be sinking my teeth into that tommorrow!
> 
> Lex (or others) - I have a question. You mention 'submemories' at the 
> end of that document about Islands, referenced below. Has 
> anybody ever 
> tried anything like this?
> 
> I'm currently working on my master's project about 
> replicating objects 
> (dpon.sourceforge.net). My current problem is how to increase the 
> 'granularity' - replicating a single object is just too inefficient 
> because objects are small; on the order of a few dozen bytes. 
> A way to 
> do this is to use 'submemories', 'segments', 'object groups' 
> or whatever 
> you would like to call them, to group related objects together and 
> replicate them as a block. Kind of like what ImageSegments do.
> 
> The way I see it, there are two ways of attacking this - the hard way 
> and the soft way. The soft way is by putting your hand into 
> the goop of 
> objects and pulling a handful of inter-related objects out. 
> That would 
> then be your segment. You can then do goopy things with object goop, 
> like splitting it in two, or merging it with another goop, or 
> throw it 
> back in the pool of goop. You would catch messages going to that goop 
> and use them to replicate the objects in that segment.
> 
> The hard way would be to make hard segments - define objects to 
> explicitely be owned by another. Then you have a sort of ownership 
> hierarchy, with owner objects acting as Interfaces (or 
> SegmentManager's?) to a segment. This is nice because you can do 
> security stuff and management stuff. Security stuff would be like not 
> allowing objects 'private' to a segment to be referenced from outside 
> (an extra layer of protection above capabilities), and perhaps vice 
> versa. Management stuff would be like you say - this segment is only 
> allowed to use so much memory, and so much CPU time and below a 
> particular priority etc. There are also a lot more possibilities. 
> Essentually it would let you make lots of mini-VM's that are 
> completely 
> isolated (except for an interface to the outside world) from 
> the rest of 
> Squeak.
> 
> Sorry; this has got a bit long. My question was: "Has anybody 
> ever done 
> anything related to grouping objects together?".
> 
> Michael.
> 
> Lex Spoon wrote:
> > If anyone wants to play with Islands, it's much easier now.  
> > 
> > Download everything from:
> > 
> > 	http://minnow.cc.gatech.edu/squeak/2074
> 
> 
>