This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Finding memory leaks


A couple of further observations after reading this thread again:

1) It looks to me like much of the issue here is the overly large heap
given the live data size.  This is generally fairly easily debuggable
with a breakpoint in GC_expand_hp_inner, and then determining why
the collector decided to expand the heap.

2) The hash synchronization code (natObject.cc) may allocate during
monitor entry.  Those objects rely on finalization to be reclaimed,
and hence may persist for longer than you might expect.  The finalization
statistics from a GC_dump() call (or just GC_print_finalization_stats)
might be interesting.  The finalization hash table could be 16K in size.
(It grows in powers of 2 if necessary.)

Hans

On Sun, 29 Feb 2004, Thomas Aeby wrote:

> On Sun, 2004-02-29 at 18:31, Andrew Haley wrote:
> > I doubt it.  Do you know what root points to these mystery structures?
> > Perhaps they're instances of Class, perhaps something else.
>
> Unfortunately there's no symbol associated with the address in the root
> - so it's just some anonymous data structure to me.
>
> Anyway, the structure is:
>
>    root
>      => block of memory (16kBytes)
>      => many small blocks of memory (16-48 Bytes typically)
>      => Java object
>
> Of course, this might be my simple marker taking something for a pointer
> that isn't actually a pointer. This doesn't explain why they aren't
> collected, anyway, then.
>
> > Like I said, we really need s full trace during gc to figure this out.
>
> I agree. Whith my approach I hoped to find malfunctions of my program -
> it's not actually worth much for debugging the garbage collector
> itself, though it points me to the fact that the garbage collector is
> either much more complex than I thought or it is malfunctionning in some
> way. Not a very precise statement ... :-(
>
> Hacking gcj in order to get the GC backtracing stuff working is out of
> reach for me, however.
>
> Best regards,
> Tom
> ------------------------------------------------------------------------
> ----
> Thomas Aeby, Kirchweg 40, 1735 Giffers, Switzerland, Voice : (+41)26
> 4180040
> Internet: aeby@graeff.com                           PGP public key
> available
> ------------------------------------------------------------------------
> ----
> I don't have to take this abuse from you -- I've got hundreds of people
> waiting to abuse me.
>                 --Bill Murray, "Ghostbusters"
>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]