Memory leak in Java app

A

Alan Morgan

I have a Java app, running on Windows, with a medium amount
of C++ wrapper code doing various arcane and boring things.
JProfiler swears that there isn't a memory leak in the Java.
Purify claims that there isn't a memory leak in the C++. According
to ProcessExplorer, however, we leak memory (or rather, the
Private Byte and Working Set keep rising). Some of this might
be induced by memory fragmentation, I suppose, but other than
that and the thought that Sun's JVM might leak memory (possible?),
I'm not sure where to go.

I'm currently using Sun's 1.5 JVM. Client and Server mode doesn't
make much of a difference (the amount of memory used goes down,
but the increase remains). I haven't tested extensively with 1.6,
but saw essentially the same behavior with my quick look.

Is futzing with the GC parameters going to accomplish anything?
Is this just expected behavior? Is the only solution to kill and
resume the app on a regular basis?

Alan
 
D

Daniel Pitts

Alan said:
I have a Java app, running on Windows, with a medium amount
of C++ wrapper code doing various arcane and boring things.
JProfiler swears that there isn't a memory leak in the Java.
Purify claims that there isn't a memory leak in the C++. According
to ProcessExplorer, however, we leak memory (or rather, the
Private Byte and Working Set keep rising). Some of this might
be induced by memory fragmentation, I suppose, but other than
that and the thought that Sun's JVM might leak memory (possible?),
I'm not sure where to go.

I'm currently using Sun's 1.5 JVM. Client and Server mode doesn't
make much of a difference (the amount of memory used goes down,
but the increase remains). I haven't tested extensively with 1.6,
but saw essentially the same behavior with my quick look.

Is futzing with the GC parameters going to accomplish anything?
Is this just expected behavior? Is the only solution to kill and
resume the app on a regular basis?

Alan
Only assume you're leaking memory if over a sufficient time period, you
get OOM exceptions. Java is a Garbage Collected environment, which
means that some objects may just hang around until the GC decides its
time to clean them up. Looking at the java processes memory consumption
doesn't tell you what is actually in use. The garbage collector usually
doesn't try very hard until the used memory gets to be very close to
"full" for the currently allocated heap size.

In other words, its normal to have memory usage creep up slowly and
then, with no warning or explanation, drop down to normal levels again.
 
A

Alan Morgan

Only assume you're leaking memory if over a sufficient time period, you
get OOM exceptions. Java is a Garbage Collected environment, which
means that some objects may just hang around until the GC decides its
time to clean them up. Looking at the java processes memory consumption
doesn't tell you what is actually in use. The garbage collector usually
doesn't try very hard until the used memory gets to be very close to
"full" for the currently allocated heap size.

I'm aware of that, but there may be some subtlties in the Java GC that
I'm missing. JProfiler claims that the heap never grows beyound about
10MB. I see regular garbage collections occurring which generally reduce
my consumption from about 9MB to about 6MB. I can run the system all day
and this won't change. However, Process Explorer insists that my app,
which started off using 30MB of private memory, is now using 60MB. Forcing
a GC via JProfiler doesn't do anything to change this.

Obviously using JProfiler is going change the system behavior and mess
with these numbers blah blah Heisenberg. I realize this is not an exact
science.

Alan
 
M

Mark Space

Alan said:
and this won't change. However, Process Explorer insists that my app,
which started off using 30MB of private memory, is now using 60MB. Forcing
a GC via JProfiler doesn't do anything to change this.

Obviously using JProfiler is going change the system behavior and mess
with these numbers blah blah Heisenberg. I realize this is not an exact
science.

Roedy's link explains that not calling dispose() on GUI objects results
in the underlying (native) objects being retained by the OS. Could be
something like that. You may have to look beyond the JVM and see what
the rest of the system is allocating on your behalf.

I'm not an expert in Windows heap analysis by any means, but if you find
some good info debugging Windows heaps please post up what you find. :)
 
A

Alan Morgan

Roedy's link explains that not calling dispose() on GUI objects results
in the underlying (native) objects being retained by the OS.

Mmm. I'm not using GUI objects but the same principles could apply to
other objects. I'll see if Purity can give me any information there.

Alan
 
R

Robert Klemme

Mmm. I'm not using GUI objects but the same principles could apply to
other objects. I'll see if Purity can give me any information there.

Did you run the JVM with verbose GC trace? Did it tell anything
interesting?

Btw, 60MB does not sound much nowadays. I believe the JVM's default for
-Xmx is 64MB so you could expect it to grow a bit more without having
to worry.

Kind regards

robert
 
K

kohlerm

I'm aware of that, but there may be some subtlties in the Java GC that
I'm missing. JProfiler claims that the heap never grows beyound about
10MB. I see regular garbage collections occurring which generally reduce
my consumption from about 9MB to about 6MB. I can run the system all day
and this won't change. However, Process Explorer insists that my app,
which started off using 30MB of private memory, is now using 60MB. Forcing
a GC via JProfiler doesn't do anything to change this.

Obviously using JProfiler is going change the system behavior and mess
with these numbers blah blah Heisenberg. I realize this is not an exact
science.

Alan

This looks like that the leak is not in Java.
To be sure the easiest way to find out whether it's a leak in Java is
to get
the SAP Memory Analyzer at https://www.sdn.sap.com/irj/sdn/wiki?path=/display/Java/Java+Memory+Analysis.
It's free and will be open sourced soon(check my blog here
https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/wlg/7637)

Regards,
Markus
 
D

David Gourley

Alan said:
Mmm. I'm not using GUI objects but the same principles could apply to
other objects. I'll see if Purity can give me any information there.

Alan

You may also want to take a look at some of the IO classes with
associated close() methods... these objects often have (in some cases
significant) native memory associated with them. If you explicitly call
close() the native memory is freed; if you don't, the memory doesn't get
freed until the object finaliser gets called (which if the object has
been promoted to the old area may never happen). I've seen one deviant
case where we got OutOfMemory because of this even though there was
plenty of free memory in the Java heap.

You may be able to allay this particular problem by tweaking GC
parameters (if it's outside your code) - as you can cause objects to
live for longer without getting promoted if this is the problem.
However (IMO) best practice is always to call a close() or dispose()
method if it exists (preferably in a finally block...)

Dave
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,904
Latest member
HealthyVisionsCBDPrice

Latest Threads

Top