Finding memory leaks

Sat Feb 28 19:36:00 GMT 2004

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.