RE: GC_DEBUG patch, again

["Boehm, Hans" <hans dot boehm at hp dot com>]

I finally checked in the GC_DEBUG patch.  I added one more patch to backgraph.c
in the process.  The final patch is attached.

On Linux at least, if you build with --enable-gc-debug, two environment
variables should now cause the generation of interesting debug output:

GC_BACKTRACES=n: At each GC sample n objects, and print the reference
chains that are causing them to stay around.  Most useful after the heap
has grown much larger than it should.

GC_PRINT_BACK_HEIGHT: Print the "height" of unreachable objects.
If this increases without bound, you are on thin ice if you use a conservative
garbage collector.  If it stays bounded, things should be OK.  For details,
see http://portal.acm.org/citation.cfm?doid=503272.503282 or
http://www.hpl.hp.com/techreports/2001/HPL-2001-251.html .  The code
behind this is immature.

Hans

> -----Original Message-----
> From: Bryce McKinlay [mailto:mckinlay@redhat.com]
> Sent: Thursday, August 26, 2004 1:13 PM
> To: Boehm, Hans
> Cc: 'java-patches@gcc.gnu.org'
> Subject: Re: GC_DEBUG patch, again
> 
> 
> Boehm, Hans wrote:
> 
> >Here is a revision of the GC_DEBUG patch for the current, 
> post-6.3-merge
> >tree.  Most of the remaining patch is to libjava/boehm.cc.
> >
> >Assuming this passes some more testing, is this OK for the trunk?
> >  
> >
> 
> OK. The clean-ups look good, thanks.
> 
> I'd like to get an idea of what would be required to enable the debug 
> routines to be selected at runtime, though. Is there code in 
> the GC that 
> assumes that only one version of the functions will be compiled in?
> 
> Regards
> 
> Bryce
> 
>

Attachment: 082704checkin.diff
Description: Binary data