[elephant-devel] db gc

[Gabor Melis]

On Thursday 03 March 2005 21:10, Ben wrote:
> Sorry for not responding to this earlier, have been occupied.
>
> Your code looks good.  Thanks for working on this.  Some points:
>
> 1) does it work with Andrew's new MOP stuff?

If it is in CVS, yes. I test against CVS HEAD.

>
> 2) the implementation you are working on is an offline implementation.
> the technical issues i had mostly had to do with online
> implementations.  i think an online implementation is probably too
> hard to be worth it at this point.

Well, meanwhile the implementation reached the proof of concept level. It 
detects garbage and collects it, but it is slow. I think there are two causes 
for this:

- db-cursor-delete is slow: only 1000-2000 deletes per second :-)

- fully deserializing everything and recording oids is easy but wasteful

Even if these problems were solved satisfactorily, I would not like to take my 
website off-line daily, so I intend to look into the incremental version, as 
well. I'm interested in those technical issues. The issue I see here is how 
to efficiently record the oid refs overwritten/created.

>
> 3) since it is offline, you can probably open sleepycat up with some
> flags which will make this go fast.
>
> 4) "Can references to a persistent object have different class names
> (maybe due to a change-class)?"
>
> it does appear this is the case.  i think Andrew is the expert here --
> Andrew?
>
> the original collector i had in mind didn't know about the classes of
> persistent objects.  it just kept track of OIDs blindly.  the
> implementation was to be a little dirtier but easier.  it was
> guaranteed then to not collect "unreferenced slots" which come from
> change-class.  of course it couldn't collect discarded slots either.
>
> it appears that maybe i'm storing objects incorrectly.  perhaps the
> right way to do this is to store objects as OIDs without classes, and
> then have a separate OID -> class table.  that way change-class can
> work correctly.  it depends on if you think change-class should update
> the DB or not, though.  (mental note to self: if one implements this,
> one should make sure the instance cache code does the right thing
> e.g. check the class before handing back a cached instance!)
>
> in some ways the change-class / update-class-for-x semantics are still
> a little fuzzy.  maybe Andrew can illuminate us here!
>
> take care, B