Invocation Problems (memory leak)

[Sheol]

Why does the GC not collect the local references created in my shared
library? How do I get these objects to collect so that I do not have a
memory leak?

JVM: Sun's 1.5.0_06 for linux.

I have a shared library that I am using behind other larger
(behemoth) programs to start a JVM and execute an existing, complex
system. I use the JNI_CreateJavaVM() to create the JVM using
JNI_VERSION_1_4 arguments. It starts without errors and I am able to use
the existing system for some number of calls. The argument list in the
interface between the shared library and the java system requires that the
shared library create objects and fill them. However, the GC will never
claim the objects created in the shared library through the JNI even
though they show up in a GC root (I have been using a profiler to help
with this). I have used PushLocalFrame()/PopLocalFrame() and
DeleteLocalRef() with no affect. So, why does the GC not collect the local
references created through the JNI? How do I get these objects to
collect so that I do not have a memory leak?

I have an incredibly small test suite that I could post for people if they
want to help find and fix this problem.

I will monitor this posting so please do not send email -- besides, I
think this address is dead anyway.

I have done the obligatory search on google, read Sun's JNI tutorial
(mildly instructive), read a good deal of the JNI specification (more
instructive than the tutorial), and read about as much as I can find on
this topic (including some book whose title I forgot already). That does
not mean I have read everything, just as much as I found.

Lastly, thanks in advance for any and all help.

 

[opalpa]

Warning: I'm not a JNI expert.

GC does not have to reclaim objects until it feels like it. If you run
your app and create lots of stuff it still does not reclaim references?
The GC waits until it believes it should clean up because resources
are scarce, is my understanding. In other words if you have plenty of
resources it will not bother reclaiming even though it could.

Also can you release your resources through some explicit call on the
objects?

Opalinski
(e-mail address removed)
http://www.geocities.com/opalpaweb/

 

[Chris Uppal]

I have used PushLocalFrame()/PopLocalFrame() and
DeleteLocalRef() with no affect. So, why does the GC not collect the local
references created through the JNI? How do I get these objects to
collect so that I do not have a memory leak?

You are using the right tools. So the only possibilities I can think of are:

1) Opalinski's suggestion (another reply in this thread). The JVM might be
perfectly capable of GCing these objects but just hasn't got around to doing so
yet. You could try invoking GC explicitly to see if that makes a difference.
OTOH, if these references are showing up as GC roots in your profiler, then
maybe that isn't so likely (assuming you are interpreting what the profiler is
telling you correctly).

2) There's a bug in this part of the JNI implementation. That's always a
possibility, especially as you are using the very latest VM, so you don't have
quite the same assurance that the feature is used by lots of other people (who
would surely have noticed the problem before you). Still, I don't think it's
/very/ likely.

So that leaves:

3) You are somehow forgetting to DeleteLocalRef() on some of the object
references you create. To me this sounds quite possible, and is certainly
where I would be looking (and double- and triple-checking) if this were my
code.

I have an incredibly small test suite that I could post for people if they
want to help find and fix this problem.

Unless someone else knows of a bug in JNI, then It probably is a good idea to
post some code. (I can look at it, if it's not too long, but can't try it out
myself it since I don't like running Linux).

-- chris

 

[Sheol]

Warning: I'm not a JNI expert.

GC does not have to reclaim objects until it feels like it. If you run
your app and create lots of stuff it still does not reclaim references?
The GC waits until it believes it should clean up because resources
are scarce, is my understanding. In other words if you have plenty of
resources it will not bother reclaiming even though it could.

Also can you release your resources through some explicit call on the
objects?

Opalinski
(e-mail address removed)
http://www.geocities.com/opalpaweb/

I should have been more explicit. If I let it run long enough, it will
fail with an out-of-memory error. I think that the GC is required to clean
up all that it can before this point.

 

[Sheol]

1) If I let it run long enough, I will always get the out-of-memory
errors. Also, I sent the "snapshots" to the profiler makers and they also
claim that the objects are showing up in a GC root.

2) I have tried JVMs from 1.5.0_01 to 1.5.0_06 with the same results. I
think I have tried them all, but I may have missed a release or two. My
guess is that it is something that I do not understand about invocation
rather than a JNI bug.

3) I have double, triple, and quadruple checked my shared library. That
does not mean it is error free; it simply means this is also my primary
guess at a fault.

I will build a zip file with the code in it. The zip file will be may be
big because of the supporting JAR file, but the actual code in question is
pretty small as things go. Lots of comments, but just a little bit of
work. Also, this code should work on any platform. The C++ code that I
wrote should conform to the ANSI standard (or what tries to be an ANSI
standard) and therefore should compile just about anywhere. I have a
make.sh script that makes the test program, so that can be used to convert
to your platform of preference.

 

[Raymond DeCampo]

1) If I let it run long enough, I will always get the out-of-memory
errors. Also, I sent the "snapshots" to the profiler makers and they also
claim that the objects are showing up in a GC root.

Which GC root? That is, have you used the output to trace it back to
the canonical object (usually a static reference or other such thing)
that cannot be GC'd? Tools like JDeveloper have helped me with this in
the past.

HTH,
Ray