Finding memory leaks

Boehm, Hans hans.boehm@hp.com
Tue Mar 2 01:49:00 GMT 2004


I should really find some time to work on the backtracing stuff ...

As far as I know, incremental GC is not turned on for gcj by default.
Hence that's not an issue.

Thread-local allocation is turned on by default.  It maintains a
separate set of free lists that are treated as reachable by the rest of the
collector.  This is implemented in pthread_support.[hc].  Basically a
GC thread structure can point to these free lists, which will then be
normally marked.  If you see several lists of objects, with each list
containing only objects of one size, I'd be suspicious that they're
thread-local free lists.

It's also fairly easy to turn off thread-local allocation to see whether
that changes anything.  (Remove the definition of THREAD_LOCAL_ALLOC.)

If you want to know why the heap got so big, it's often useful to set a
breakpoint in GC_expand_hp_inner.

Hans

> -----Original Message-----
> From: java-owner@gcc.gnu.org 
> [mailto:java-owner@gcc.gnu.org]On Behalf Of
> Thomas Aeby
> Sent: Sunday, February 29, 2004 9:50 AM
> To: Andrew Haley
> Cc: ovid@mailandnews.com; Java GCJ Mailing List
> Subject: Re: Finding memory leaks
> 
> 
> 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"
> 



More information about the Java mailing list