This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: Finding memory leaks
On Sat, 2004-02-28 at 20:35, Andrew Haley wrote:
> Does a trivial app (concatenate a ton of strings, throw a way the
> result, loop) collect OK for you? It does for me.
Unfortunately - at least in my case - trivial apps seem to always
behave as expected :-(
> 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.
Some good things for debugging (and that I'm missing in - hmh - some
very wide-spread JVMs, too :-)) were:
- some (native) Java procedure that just returns a Vector/Enumeration
with pointers to every object currently on the heap. This way a
program can debug itself very easily and it's very simple to find
memory leaks. It's not even very difficult to implement, I guess.
I've always found Thread.enumerate() very useful for finding
looping or (dead-)locked threads. Something like
System.enumerateObjects() would serve equally well for debugging
memory allocation problems.
- boehm GC can be built with backtracing information being kept.
This information would be very interesting - but it seems that
gcj won't build with backtracing enabled(?). This is a pity ...
- Maybe some of the effects I see are caused by incremental
collection. If yes, some method of forcing the garbage collector
into a non-incremental mode or - even better - of forcing one full
none-incremental mark/sweep run on demand would make things much
more transparent for debugging (just provided that System.gc() or
GC_gcollect() doesn't do that, yet).
Best regards,
Tom
----------------------------------------------------------------------------
Thomas Aeby, Kirchweg 40, 1735 Giffers, Switzerland, Voice : (+41)26
4180040
Internet: aeby@graeff.com PGP public key
available
----------------------------------------------------------------------------
If it's broke, fix it (The MS-DOS way). If it aint broke, don't touch
it (The Unix way). If we can't fix it, it ain't broke (Maintainer's
Motto)
Hey, break it anyway,then we'll learn how it really works(Systems
Programmer)