This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: Finding memory leaks
- From: Rutger Ovidius <ovid at mailandnews dot com>
- To: Thomas Aeby <aeby at graeff dot com>
- Cc: Java GCJ Mailing List <java at gcc dot gnu dot org>
- Date: Sat, 28 Feb 2004 09:40:34 -0800
- Subject: Re: Finding memory leaks
- References: <1077572103.12067.93.camel@susix>
- Reply-to: ovid at mailandnews dot com
Hi,
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.
Regards,
Rutger Ovidius
On Monday, February 23, 2004, Thomas Aeby wrote:
> Hello,
> 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).