[Gc]: Heap traversal

Boehm, Hans hans.boehm at hp.com
Tue Oct 20 16:04:29 PDT 2009


Sorry.  That's what you get for asking hard questions :-)

I think the core problem is that the meaning of any such function tends to be somewhat ill-defined.  There is currently a GC_apply_to_each_object() in backgraph.c that we could move someplace and export.  The problem is that the "objects" you get will probably include stuff in per-thread free-lists.  And if we don't implicitly call GC_gcollect just before, you may got other free objects as well.  Thus the function applied to each object probably has to be extremely defensive.

And it's not clear that any of this works unless you hold the allocation lock during the traversal.  That's prone to deadlocks if the callback indirectly allocates.

If we do want to export something along these lines, I think we should move the implementation from backgraph.c into a separate file, and perhaps have the public variant garbage collect and give us only marked objects (incl. on thread local free-lists) holding the lock throughout the process.   We could think about clearing per-thread free-lists in addition to garbage collecting, but I suspect that introduces messy races with simultaneous allocation, and we don't really want to go there.

I'd also be tempted to put the interface into gc_mark.h or a new header file, since this is unavoidably an ugly, very low-level interface tht requires some awareness of GC implementation details that I'd rather hide.

Hans

> -----Original Message-----
> From: gc-bounces at napali.hpl.hp.com 
> [mailto:gc-bounces at napali.hpl.hp.com] On Behalf Of Ivan Maidanski
> Sent: Monday, October 19, 2009 10:16 PM
> To: gc at napali.hpl.hp.com
> Subject: Re: [Gc]: Heap traversal
> 
> Hi!
> ludo at gnu.org (Ludovic CourtХs) wrote:
> > Hello,
> 
> Hans -
> could you also answer this post (just not to have it in a backlog)?
> 
> > 
> > The former GC of Guile provided information about the (approximate) 
> > number of live objects of each data type:
> > 
> > --8<---------------cut here---------------start------------->8---
> > guile> (pp (gc-live-object-stats))
> > (("dynamic-state" . 2)
> >  ("complex number" . 7)
> >  ("thread" . 1)
> >  ("frame" . 19)
> >  ("macro" . 72)
> >  ("srcprops" . 2898)
> > 
> > [...]
> > 
> >  ("cons (non-immediate car)" . 41614)
> >  ("jmpbuffer" . 1))
> > --8<---------------cut here---------------end--------------->8---
> > 
> > With libgc, heap traversal can be done with  
> GC_apply_to_all_blocks?()'.
> > This is what GCJ does
> > 
> (http://google.com/codesearch/p?hl=en&sa=N&cd=2&ct=rc#nnPz_KYt
> 5WI/com/avtrex/test/memory/GCInfoC.cc&q=GC_enumerator&l=264).
> > 
> > The problem is that  GC_apply_to_all_blocks?()',  struct hblk', and 
> > the macros and functions that manipulate blocks and block 
> headers are 
> > all private.
> > 
> > What would be the best way to expose just enough of these 
> internals so 
> > that one can write this kind of heap traversing code?
> > 
> > Thanks,
> > Ludo'.
> 
> Bye.
> _______________________________________________
> Gc mailing list
> Gc at linux.hpl.hp.com
> http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
> 


More information about the Gc mailing list