[rucksack-devel] GC problems

[Arthur Lemmens]

Edi Weitz wrote:

> Yeah, I realize I'm soliloquizing... :)

Now it's my turn ;-)

> 1. Hook into the host (Lisp) GC (in an implementation-dependent way,
>    obviously)

I try to avoid implementation-dependent solutions as much as possible,
and hooking into the implementation's GC is not the kind of thing that
is easy to port (unlike simple locking, for example).

So I'm not going to do this unless there really is no other way.

> 2. Similar, but portable and coupled to transactions: Whenever a
>    PERSISTENT-THING object is created, annotate its object ID in an
>    IDS-IN-USE structure (for example a hash table) belonging to the
>    current transaction.  During (Rucksack) GC, add the IDs in this
>    structure to the roots.  IDS-IN-USE will obviously vanish once the
>    transaction is finished.
>
>    The idea is that transient references to persistent objects which
>    were created in the current transaction are also traversed during
>    the scanning phase of the GC.

I think that my solution of saving dirty in-memory objects to disk
when the scanner encounters them will be easier and more reliable.
Do you agree or do you think that your #2 approach is still worth
exploring?

> Both "solutions" fail because objects are in a way written to disk too
> late

Exactly.  That's why I prefer to write them to disk early enough ;-)

> A. We could abandon the idea of a concurrent GC and only run the GC
>    when there's no transaction, similar to what Plob! does.

Yeah, that's an "if everything else fails" solution.  But I'm not
ready for that yet.

> B. We could abandon the idea of roots and reachability and instead
>    explicitely delete objects, similar to what AllegroCache does.

That's an "if everything else (including off-line GC) fails" solution.
I don't think I'll ever be ready for that...

Arthur