That's very interesting (the copy on write stuff)...a lot of the problems we
deal with today revolve around the synchronization of the state of an object
with some external (or internal) copy or representation of that object.
Having a copy on write capability is integral to managing this state
synchronization.

Wouldn't it be nice to have a platform that:
  - had disk based objects, using memory only for method execution with an
intelligent caching scheme
  - incorporated some of the language ideas explored by Self
  - offered copy on write capabilities (and transactions built on top of
that)
  - and of course, it would run all of the fun stuff in Squeak

Regarding the object table, much of the rationalization for dropping it in
Squeak seems to come down to performance, yet VisualWorks achieves a much
higher level of performance than Squeak, and it has the benefits of a OT
(correct me if I'm wrong here)...why was it decided to drop the object
table, rather than achieve performance using many of the same techniques as
VW?  Something tells me that it has to do with portability...where am I
wrong?

- Stephen

> -----Original Message-----
> From: Tim Rowledge [mailto:tim at sumeru.stanford.edu]
> Sent: Tuesday, March 27, 2001 10:56 PM
> To: squeak at cs.uiuc.edu
> Subject: Re: Micro Squeak
>
>
> Another possibility, but that involves quite lot more work, is to revert
> to an Object Table and use copy-on-write semantics.
>
> Many years ago (1989), in a galaxy far, far, away (Cambridge, UK), I did
> the VM work for the Active Book Company. The Smalltalk used was a
> derivative of a derivative of Eliot Miranda's rather nice BrouHaHa vm,
> hacked about mercilessly for various reasons. To cope with a mainly ROM
> world, I used the OT's indircetion to my benefit. All objects were in
> ROM to start with and when any prim or bytecode tried to write into ROM
> it was caught, the object copied to RAM and a the OT data pointer
> updated. After that, the write could proceed without problem. It worked
> amazingly well and nobody ever spotted a problem with it in tens of
> thousands of hours of running. I even managed to come up with a way to
> save the delta from the ROM (by scanning the OT, finding all the objects
> now in RAM and saving them) so that typical working 'images' were
> 70-80kb. Loading these 'images' took very little time and was pretty
> much a patching operation. The machine has 1Mb ROM, 1Mb RAM to cover the
> OS, a fax filing system and screen and all working space. It was snappy
> as hell and could probably be produced for about $100 these days. Sigh.
>
> Anyway, you could probably do similar with the current Squeak
> ObjectMemory format, but it would be trickier since there is potential
> for a major swarm of copy/update with direct pointers. For restricted
> applications (no changing classes, move class variables that get written
> to a global dict, stuff like that) it would be ok.
>
> If anybody wants it done, I'm available for the usual ursurial rates.
>
> tim
>
> --
> Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
> Strange OpCodes: MW: Multiply Work
>