Chris,

Chris Muller wrote:

Hi Stephen, let me see if I can answer your questions:

...

I notice that you are assigning oids to every object that

is stored in Magma and using a WeakKeyIdentityDictionary for storing the oids. One issue I had with that approach is that I think it runs into scalability issues when you approach and surpass 4096 objects (due to the number of bits available for the identity hash). Is there a way to make this scheme more scalable? Or, is it possible that it will be rare to have more than 4000 persistent objects cached on the client?

A: I don't think it would be "rare" to have more than 4K objects in a medium-sized program. However, it was written with the expectation that identityHash will be fast. If there is a scalability problem w/ weakIdentityDictionaries greater than 4K in size, then there may be a scalability issue w/ Magma.

The identity hash in Squeak is only 12 bits. There has been a lot of discussion in the past regarding how to improve this...you might be able to get better scalability by spreading out the hash (and perhaps subclass WeakKeyIdentityDictionary)...you'd still get the same amount of collisions, but presumably, you wouldn't have to scan nearly as far to get a match or an empty slot.

======

How are you tracking the changed objects? A: Take a look at MaTransaction>>markRead:. MaTransaction maintains an IdentityDictionary whose keys are the read object, values are a shallowCopy "backup". When you commit, it zips through the keys and values and does an identity compare of each objects variables (see implementors of maIsChangedFrom:). This may seem like a lot of work, but its actually suprisingly fast. Additionally, I prefer this "copy and compare" method of change detection because it offer the most transparency.

After I wrote the email, I discovered this...very clever! 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. It looks new objects get stored (during commit) when they are referenced from other objects that are already in the db...when they are stored, you then record the shallowCopy backup...that way the object is part of the scan to detect changes. Is that correct?

========

It takes a long time to establish a MagmaSession (especially after some objects have been populated in the server)...can you describe what's happening when connecting? A: Hmm... I've never noticed that taking a long time. If you look at the MamgaSession>>connectAs:maximumNumberOfChallengers: it summarizes what MamgaSession>>happens upon connection. Basically, we have to get the classId's and definitions of all the classes that are known to the repository. The current class definition defined in Magma has to match what is in your image or it won't let you connect.

I haven't posted the Swiki page yet about how to tell Magma to "upgrade" a class to a new version, but you can see examples in MagmaTestCase.

==========

I see that you are using a stubbing mechanism (ala GemStone) that uses a ProtoObject and #doesNotUnderstand: to transparently forward messages to the real object. Are you also using #become: to change these objects into their real counterpart? If so, won't this present a performance issue under certain circumstances (where one or both of the objects are in old space)? Also, did you implement a "stubbing level" mechanism ala GemStone? A: I use becomeForward:. I've not noticed any performance issues in my "small" volume tests. If this causes a performance problem due to them being in oldspace, do you have an alternative?

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.

Perhaps I've been a little too quick to dismiss #become: though...if you examine normal usage patterns, it's probably the case that the vast majority of your #become: calls are happening with two young objects...which is fast.

========

Is there any kind of cache control in Magma? For example, if I have a client that is running for many weeks and accessing lot's of objects, once they are pulled from the server to the client, are they going to stay in the client indefinitely? Is there some way of controlling how many objects are retained in the client's object memory?

A: The only "caching" Magma does is in weak collections, so there shouldn't be anything that you don't cache yourself.

Avi Bryant wrote: "Right, but once a stub gets replaced with a real object, the real object will never get replaced back with a stub, correct? Which means that, since the session has a reference to the root, and the root has a reference to every other object in the database, once an object is pulled into the client it will never be garbage collected unless it is removed from the database. This can be a problem for long running clients. I think what Stephen is suggesting is that, for example, you periodically becomeForward: objects back into stubs that have not been used for a certain length of time."

Avi is summarizes it correctly...the issue I see is that you can eventually get the whole database in memory (if your application runs long enough and works with enough of your dataset). One solution might be to simply restart the image when it grows beyond a certain threshold (I do that right now with swiki.net). Here's a caching design I'm working on:

The algorithm is an approximate LRU and works by counting the number of dereferences (when an object is actually retrieved from the db) and object stores (when an object is saved). Each cached object (actually an object cluster in my case) has an age. After a threshold is reached (say 1000 derefs), I scan through the cached objects (actually clusters) incrementing the age of relatively young references, and flushing the objects whose references have reached a maximum age (say 5). When an object is dereferenced, the age gets reset to 0. So, the age actually tells us how many aging scans have occurred since the last time the cluster was dereferenced. Thus, older objects have not been accessed in a while (note: I chose not to implement transparent proxies...you access your cached objects by holding onto an PdbObjectReference, which holds the root of a cached cluster of objects...thus, you must always access your cached objects by sending the #deref message to a PdbObjectReference). Also, I have to check all of the process stacks to make sure that an object is not current being accessed before flushing it (probably a rare occurrence anyway).

I'm thinking that this type of caching might work well in practice. It doesn't set any hard limits on the number of cached objects...so, if you have a very large and active working set, they should all stay young and stay in memory. A possible improvement might be to add a hard limit on the number of cached objects and have have a deref trigger a scan (in addition to the deref counting) if that deref would cause the limit to be exceeded.

- Stephen