RE: [Fwd: Re: Debugging memory leaks]

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

I haven't tried it.  But if I understand it correctly, I agree.

It might be helpful tot contrast it with the --enable-gc-debug facility
that Andrew mentioned earlier.

I think the package that David posted:

a) works with a standard gcj build, a big advantage.

b) dumps the whole heap, a mild disadvantage.

c) presumably can do a nice offline analysis.

The --enable-gc-debug facility

a) currently requires a custom libgcj build.  (I've been intending to
fix this, but it doesn't look like it's going to happen real soon.  And
it's hard to do that without slowing down the collector.)

b) does minimal analysis on-line.

c) uses the collector's own information about the source of references.

I expect that for most uses this package is much more convenient than
--enable-gc-debug, at least as it currently stands.  There are still
some cases, particularly when debugging the collector itself, or when
there is an issue related to possible pointer misidentification when it
might be important to get the collector's actual reachability
information and --enable-gc-debug would still be the preferred option.
But for most Java-level issues, I doubt that's necessary.
(--enable-gc-debug also allows some kinds of testing, e.g. for potential
but unobserved leaks due to conservative GC, that's outside of this
discussion.)

I noticed that one or two of the routines in David's code, particularly
the one to dump /proc/self/maps have (somewhat more robust?) equivalents
in the GC itself.  If this code is merged, it would be good to just use
the GC routines, extending them a bit if necessary.

Hans

> -----Original Message-----
> From: java-owner@gcc.gnu.org [mailto:java-owner@gcc.gnu.org] 
> On Behalf Of Tom Tromey
> Sent: Saturday, November 26, 2005 1:53 PM
> To: David Daney
> Cc: Craig A. Vanderborgh; java@gcc.gnu.org
> Subject: Re: [Fwd: Re: Debugging memory leaks]
> 
> 
> >>>>> "David" == David Daney <ddaney@avtrex.com> writes:
> 
> David> This is a message I originally sent privately to Andrew Haley, 
> David> however
> David> it might be useful with your problem as well (and the 
> gcj community in 
> David> general).
> 
> FYI I didn't look at the code.  However, I think the idea is 
> a great one.  We definitely could use a tool like this in the 
> core.  So, I'd like to encourage you to submit it...
> 
> thanks,
> Tom
> 
>