Magma design

Avi Bryant avi at beta4.com
Sat Aug 3 07:14:27 UTC 2002


On Fri, 2 Aug 2002, Stephen Pair wrote:

> Since you only need to do the scan when you commit, it's not a
> horrible price to pay.  I was baffled by how Magma was able to detect
> changes in brand new instances I was creating...I even tried to fool
> it, but it worked like a charm.

This seems like it would also be a problem for long running sessions - as
you bring in more and more objects, the scan will take longer and longer.

> Unfortunately no...I've always been leary about solutions that require a
> #become: (or #becomeForward:) due to the potential performance issue.
> Squeak has a direct mapped memory model, which means that if you swap
> the identities of two objects, you must scan all of memory (unless
> you're dealing with two young objects).  You can avoid some of the
> performance issues if you can bunch up a lot of objects (this is why
> Squeak's #become is actually based on
> Array>>elementsExchangeIdentityWith:).  I don't see a way of bunching up
> a lot of stubs though.

Depending on the protocol, you often bring in clusters of objects at once
from the server (I think Magma calls this the "read strategy", and you can
modify it).  So these can all be becomeForwarded at once.

The easiest way around #becomeForward: is to simply keep the proxy around
and have it forward all its messages to the real object.  When I was
playing with a GOODS client I actually had #becomeForward: in the other
direction, in that whenever you did a commit it would replace all of the
new objects with proxies that pointed to them.  The proxy was a sort of
"object manager" that tracked which objects were touched by the
transaction, had methods for lock management, and so on.

Actually, with the recent interest in object databases I'm thinking about
reviving that GOODS client... if anyone would be really interested in it
let me know.

Avi




More information about the Squeak-dev mailing list