Re: Finding memory leaks

[Andrew Haley <aph at redhat dot com>]

Rutger Ovidius writes:
 > 
 > On Monday, February 23, 2004, Thomas Aeby wrote:
 > 
 > > I'm trying to find memory leaks in one of my Java programs. So far I
 > > have tried adding a small native C routine just using GC_* calls in
 > > order to dump out a list of objects in use and added a little Perl
 > > program taking this list, finding the associated classes' names and
 > > printing some statistics. Rather than the expected "oh, I get increasing
 > > numbers of class X instances" I see huge numbers of objects I cannot
 > > find any reason why they shouldn't be collected by the garbage
 > > collector (like e.g. FileInputStream/FileDescriptor objects, byte[] and
 > > char[] arrays, Date stuff, etc. which are mostly allocated/valid in a
 > > local block only).
 > 
 > I'd be very interested to hear what you find out, if anything.
 > 
 > Does your app collect properly with sun's java?
 > 
 > My app runs fine in sun's java; all objects are properly collected. But in
 > gcj it seems like it doesn't feel like collecting all objects so memory
 > leaks until there is no memory left.
 > 
 > I don't know how to narrow this problem down (trying to write simple test
 > cases just isn't working out), and it is _very_ frustrating.

Does a trivial app (concatenate a ton of strings, throw a way the
result, loop) collect OK for you?  It does for me.

public class gc
{
  static public void main (String[] s)
  {
	for (int i=0; i<100000; i++)
	  {
		String zz = "          ";
		for (int j=0; j<20; j++)
		  zz += zz;
	  }
  }
}

There is always a risk that because of conservative collection we're
incorrectly marking a few objects, but that doesn't sound exactly like
the problem you're having.

I've been thinking about this.  What we really need is a mode that
prints out every object found during the sweep in such a way that you
can see how everything has been reached.

Andrew.