[Gc] Re: Weak hash tables and cycles
hans.boehm at hp.com
Fri Nov 7 11:58:36 PST 2008
> -----Original Message-----
> From: gc-bounces at napali.hpl.hp.com
> [mailto:gc-bounces at napali.hpl.hp.com] On Behalf Of Ludovic Courtès
> Sent: Friday, November 07, 2008 6:33 AM
> To: gc at napali.hpl.hp.com
> Subject: [Gc] Re: Weak hash tables and cycles
> Hi Hans,
> Hans Boehm <Hans.Boehm at hp.com> writes:
> > If you leave the disappearing link to K, but then hide the
> link to V
> > from the collector and register a finalizer for V, V's
> finalizer will
> > be invoked ater a collection during which V is only
> reachable from the
> > table. V's finalizer can check whether the disappearing
> link to K is
> > still there. If it is, it simply reregisters itself as a finalizer
> > for V. If the disappearing link is gone, it doesn't reregister
> > itself, allowing V to be collected in the next cycle.
> Hmm, good idea.
> (Another way to look at it is that we're always creating
> doubly-weak hash tables, but when we really want a weak-key
> hash table, a finalizer for V is created to keep it alive.)
> However, this technique requires a way to multiplex
> per-object finalizers, so that the finalizer registered for V
> by the hash table implementation doesn't override a previous
> user-specified finalizer.
> It looks like the need to multiplex per-object finalizers
> arises quite often. It was also highlighted in
> 3-03/msg00013.html .
> Maybe libgc could provide a facility for this?
I agree that this could probably be improved. Currently you're stuck with one of the techniques proposed there: You either have to chain the finalizers or add your own layer. Chaining is fairly easy if the original client code never removes finalizers without running them, but otherwise can be painful.
> Thanks for your help,
> Gc mailing list
> Gc at linux.hpl.hp.com
More information about the Gc