How memory leaks in java

[Thomas Weidenfeller]

Tools for finding object leaks are light years ahead of the tools to
locate such problems in C/C++ code. It would have been problematic to
have a runtime tool that could find memory leaks in an arbitrary C/C++
binary in the way that OptimizeIt can locate object leaks in a Java
program.

Give Purify a try in your next C/C++ project (esp. if you develop on a
Unix system like Solaris). You will be surprised

FWIR, the way people dealt with such problems was to write
their own wrappers around malloc()/free() or buy commercial packages
that did the same. But you had to deal with things like this at
compile time, and you often had to change the actual source code to
comply with the semantics for the malloc()/free() wrappers. Ugly.

The above mentioned tool instruments the compiled binary program, so it
also covers any third party and operating system libraries linked
(static or dynamic) into the C/C++ program, too. You don't even need the
source code at all. You will be surprised how many strange things are
already going on in the OS libraries. Binary instrumentation is not only
set up to discover memory leaks, but also out of bounds errors, stack
access errors, uninitialized memory reads and a bunch of other things I
don't remember at the moment.

Doneside: Instrumentation takes time and memory. Also the resulting
binary runs slower. The Solaris GUI is poor (maybe this has changed
since I used it the last time). In addition the testing should be best
combined with a code-coverage analysis to ensure only few stones are
left unturned.

/Thomas (just a long-time user)

 

[Stephen Kellett]

Tools for finding object leaks are light years ahead of the tools to
locate such problems in C/C++ code.

I disagree.

It would have been problematic to
have a runtime tool that could find memory leaks in an arbitrary C/C++
binary in the way that OptimizeIt can locate object leaks in a Java
program. FWIR, the way people dealt with such problems was to write
their own wrappers around malloc()/free() or buy commercial packages
that did the same. But you had to deal with things like this at
compile time, and you often had to change the actual source code to
comply with the semantics for the malloc()/free() wrappers. Ugly.

Thats not how it is done these days. Modern C++ tools intercept the
allocation and deallocation at the point in the code they are performed.
No modification of source or binary. The instrumentation is done at the
point the DLL is loaded (just as JVMPI allows you to do this at the
point the class is loaded).

I'm thinking of Memory Validator.

Its not ugly, its elegant, fast and trouble free, although there are
tools that do force you to rebuild your software or lengthy
post-processing (and I agree these are not elegant at all).

As for detecting leaks, you just run your program and it shows you the
leaks when the program is finished. No messing about with do a GC, did
the memory usage increase? type of scenario that you are forced into
with a GC system (its not just Java that has this issue). Of the 2,
detecting leaks in C/C++ system is much easier than detecting loiterers
in a GC system.

I've only worked with OptimizeIt a limited amount several years ago. I

I wish I could say the same. I thought it was an awful interface that
hid a lot of information from you.

Stephen

 

[=?ISO-8859-1?Q?Daniel_Sj=F6blom?=]

I disagree.

I agree with the disagreement. Modern memory checking tools for native
code are very sophisticated and they definitely do not require
recompilation of apps. They typically check each write to memory
(catching buffer overruns among other things) and track each memory
allocation (catching memory leaks and bad frees). Some even track open
file descriptors. Download Valgrind for a free demonstration.

 

[Roedy Green]

You can't "leak" but you can "loiter"/"packrat".

The effect is the same, you use up all your RAM.

A leak is an object with nothing pointing to it that can't be GCed.

This can't happen in Java.

When you packrat you hold references to objects you will never use
again. EVERY program packrats to some extent. There is simply no way
to know if you will ever need them again. When you go crazy holding
onto things NO WAY you could ever need, that is packratting.

Java interfaces with progams written in C++, most notable the GUI. It
does not have automatic garbage collection. You have to help it along
with dispose methods. If you fail to do use them, the GUI will bloat.
This is outside Java's address space.

Java itself does a little excessive packratting -- e.g. holding onto
Frames and unused Thread objects. In each case Sun could explain why
they had to hold on just in case, but in practice if you are not
careful you can waste RAM.

 

[Roedy Green]

Give Purify a try in your next C/C++ project (esp. if you develop on a
Unix system like Solaris). You will be surprised

no success on finding a home page for Rational Purify. Do you have one
for http://mindprod.com/jgloss/profiler.html ?

 

[Thomas Weidenfeller]

no success on finding a home page for Rational Purify.

Rational has been borged by IBM. Deep down in IBM you find

http://www-306.ibm.com/software/awdtools/purify/

with some limited information.

Do you have one
for http://mindprod.com/jgloss/profiler.html ?

Purify is mainly for C/C++, the current version is supposed to support
Java, but I never used that.

/Thomas