[Gc] libgc not collecting objects with cyclic references ?

Boehm, Hans hans.boehm at hp.com
Mon Mar 19 16:50:05 PST 2007


> -----Original Message-----
> From: gc-bounces at napali.hpl.hp.com 
> [mailto:gc-bounces at napali.hpl.hp.com] On Behalf Of Christophe Meessen
> Sent: Monday, March 19, 2007 6:32 AM
> To: gc at napali.hpl.hp.com
> Subject: Re: [Gc] libgc not collecting objects with cyclic 
> references ?
> > Bruce Hoult wrote:
> >
> > If A has a pointer to B then it's presumably using B in 
> some way, so 
> > you can't finalize B first because then things in A may 
> crash.  But if 
> > B has a pointer to A then presumably it's using A in some 
> way, so you 
> > can't finalize A first because then things in B might crash.  It's 
> > insoluable.  The GC hasn't got enough information to know what is 
> > safe.
> I thought that one of the purpose of a finalizer is to solve 
> to issue you describe. Suppose A is an element in a doubly 
> linked list to be collected, the finalizer of A has simply to 
> detach it from the list to resolve the issue.
The issue doesn't really need solving unless there is a finalizer.  The
collector has no problem reclaiming cyclically connected memory.

With most garbage collectors, you are wise to avoid finalizers if you
can.  This one falls into that category.  You'll be much happier with
the performance if not too many objects do this.  (Under 1% is probably

> Is the destructor registered as a finalizer function and is 
> the destructor called on collected objects derived from the gc class ?
If you're using gc_cpp.h, then you need to inherit from gc_cleanup to
use the destructor this way.  And it's not clear that this was a wise
API decision.  Destructors and finalizers are really different.


More information about the Gc mailing list