LOOM (was: Delegation and ...)

Jecel Assumpcao Jr jecel at merlintec.com
Thu Aug 23 17:17:44 UTC 2001


On Wednesday 22 August 2001 22:46,  Stephen Pair wrote:
> > I mentioned on the Squeak list some designs I have considered over
> > the
> > years for this. I don't think a consumer quality system is possible
> > without it. Things are simply not automatic enough.
>
> I'd be interested in hearing those designs...I'm working on a design
> myself...

Well, it probably isn't worth cross posting here. I am not sure whether 
the thread should go on in the Squeak list either (in the thread 
"[Cross-space references] NewtonOS and Sessions"). BTW, I'll answer 
here a question you made there -

> Would this work?  Has it been done before?

Ian Piumarta is the right guy to ask about this. See

     http://www-sor.inria.fr/projects/sspc/

There are other projects at SOR that are related to this as well.

> I've been reading the Kaehler's LOOM stuff and that's been
> very helpful in identifying the things I need to watch out for. 

Though LOOM was created to eliminate the problems with OOZE, it is 
worth knowing that system as well.

   "Virtual Memory for an Object-Oriented Language"
  by Ted Kaehler
  pages 378 to 387 in Byte Magazine, August 1981, Volume 6 Number 8

> I'm
> shooting for something that will make incremental persistence fast,
> and will provide a commit primitive that will ensure everything is on
> disk.  Looks like the LOOM design would be expensive if you want to
> make sure everything was saved (requiring a scan of object memory I
> think).

You must scan the whole object table and flush any "dirty" objects back 
to disk. This is normally done in the background continuously, but you 
might have to force a full scan in order to commit.

I would consider the system created for the Mushroom project to be an 
evolution of LOOM:

     http://www.wolczko.com/mushroom/index.html

See the garbage collection papers, specially the last one.

> Actually, I'm amazed that this hasn't been a higher priority with
> SqC...you really can't consider Squeak as an OS without a solution in
> this area.  And, it's been done in so many other contexts...why not
> Squeak?  Makes me wonder if there's something I'm missing?

Too many virgin PhDs have been sacrificed to this dragon for them to 
undertake such a project lightly. I wouldn't say it has ever been done 
*right* in any other context.

-- Jecel



More information about the Self-interest mailing list