[Zodb-checkins] CVS: Zope3/lib/python/Persistence/BTrees - BTreeTemplate.c:1.1.2.15 BucketTemplate.c:1.1.2.16

[Jeremy Hylton]

>>>>> "TP" == Tim Peters <tim.one@comcast.net> writes:

  TP> Jeremy, don't these routines need to unghostify?  I also
  TP> rearranged code on the bet that they do, but didn't finish that
  TP> job.

I'm not sure, but I think these routines should *not* unghostify.  If
the traverse routine unghostified an object, then every time Python's
garbage collector runs the entire BTree will be loaded from disk,
unpickled, and re-instantiaited.

Yikes!  (Think about ZCTextIndex.)

Since the BTrees are persistent objects, the persistent storage is
responsible for detecting cyclic garbage.  FileStorage does this when
it is packed.  Other storages have other mechanisms.  If the storage
is going to detect and remove the cycles anyway, there's little need
to have Python's GC mechanism do anything.

This observation about the storage detecting cycles makes we wonder
whether BTrees should be play the GC game at all.  But they still
should.  It's possible for a BTree object to be created without
actually being storage in a persistent database.  (A BTree only
becomes persistent when it is reachable from the root of a database.)
For these non-persistent objects, we should detect cycles.

Perhaps the GC code should exploit more knowledge of the persistent
mechanism.  In particular:

    - If the po_oid slot is NULL, the object hasn't been stored in a
      database yet.  It should be visited.

    - If the po_state is GHOST, then all of the data pointers are NULL
      and it doesn't need to be visited.

Still not sure if we should visit un-ghosted objects with a valid
po_oid slot.

Jeremy