[ZODB-Dev] ZODB cache reimplementation

[Toby Dickenson]

>> I am currently undecided between two implementations. Variant A is very
>> similar to what you describe below.
>>
>> Variant B does not use weak references. This adds implementation
>> simplicity, which is its main advantage.

My current development snapshot is available at 
http://www.zope.org/Members/htrd/cache

I will followup with documentation and an analysis in a subsequent email.

>> I dont see a clear advantage to
>> automatically removing an object just because it has no references. Of
>> course objects with no references are likely to remain unused, and the LRU
>> rule will then remove them.
>
>Advantages of weak references (and separating ghosts):
>
>- Objects are removed from memory as soon as possible

Hmm. thats not always a blessing (if it was, we could do without this cache 
completely ;-)

>- There are fewer objects to scan

Indeed. I had underestimated the importance of this.

In my current implementation (Variant B) I am seeing that 90% of objects are 
never touched; they are the ghost children of popular objects (ghosts because 
they, unlike their parent object, are not popular). These ghosts are always 
scanned before the real work can proceed. It is only adding about 6ms to a 
worst-case scan, but I think this does justify the complexity of weakrefs.

>- You have better information on memory usage, because you track
>  how many objects are ghosts.

I agree with ghost-tracking, independent of weak references.

>- The active list is not really an active list but a ghostifyable
>  list. IOW, it should only contain objects in the up to date
>  state.   We might want to keep ghost, and ghostifyable counts
>  to inform GC.

Yes

>> Variant B adds a small memory overhead.....
>
>I don't follow this.

The overhead does indeed seem to be small, so I guess you dont need to.

>> This may also add a performance overhead, if it means we have to check
>> more objects in each scan.
>
>Yes.

As I mention above, I am now persuaded by this.

>> It would be nicer to play fair with the Dictionary implementation, and
>> allow him to keep a reference count on his referent.
>
>She does. In my scheme, the dictionary has a counted reference to the
>cache reference. If we get rid of the cache reference, then the persistent
>object reference would be uncounted and we'd have to be absolutely sure
>that we can remove the object from the dictionary. Guido is confident that
>this is safe, assuming, that the keys (oid) don't change their value or
> hash.

Nice. Ill give it a try.