Tim Rowledge wrote:
> "Stephen Pair" <spair at acm.org> is claimed by the authorities 
> to have written:
> 
> > I'm attempting to build a BerkeleyDB persistence solution 
> for Squeak.  
> > I had hoped that I could do this without modifying the 
> VM...however, 
> > I'm coming to the conclusion that a few key modifications to the VM 
> > would make life much simpler.
> After reading this thread and musing awhile, I have to say 
> that I would be inclined to use a VM with an Object Table for 
> this kind of work. It makes assorted becomes and forwardings 
> a lot simpler, provides a full 30-odd bit hash for any object 
> and just seems to offer quite a lot for the money.
> 
> tim

Well, do you happen to have one that will interpret a Squeak image?  One
of my goals was to do something that would not require too much
modification of the current VM.  Adding an object table is much more
than I want to take on.

I was thinking about the issues with not having an OT in squeak, and how
we might work around them...with the "forwarder" that I mentioned in my
earlier post, you can do fast identity exhanges on any objects in the
image...clone the two objects involved, collapse the old ones into
forwarders and point them at the other's clone, then exchange the hash
bits...not as quick at the OT, but darn close.  I'm planning to
implement a couple of become primitives using this technique.

Also, regarding hash bits, I'm not all that certain that it's such a
huge issue...I've created extrememly large ExtendedAttributeDictionaries
(where every object in memory was a key)...in fact, as I'm writing this,
I just created an ExtendedAttributeDictionary with 350,000 entries.
Doing a single lookup is not even measurable.  Doing 1000 lookups took
about 26ms (on a 700mhz Athlon).  Key removals are also fast.  Of
course, the ExtendedAttributeDictionary does incorporate the class'
identityHash...but, if you really needed to use #become: on a key, you
could hook in and make sure that the parties involved get repositioned
(after all, you probably won't have too many really big dictionaries).
Removing the class' identityHash doesn't seem to degrade performance by
that much either...just a random sampling took anywhere from 20ms to
95ms to do 1000 lookups on a 350,000 element ExtendedAttributeDictionary
using "object identityHash hashMultiply" for the hash function.

So, I'm not so sure that an object table is necessary.  Besides the hash
and fast become operations, what other advantages are there with an OT?

- Stephen