5

I'm using jvisualvm to check for memory leaks in my application. When I do a heap dump, sometimes several objects are being held open that should have been garbage collected.

When I do a "Show Nearest GC Root" command on them, it shows me that the root is a class which I defined which implements the interface Runnable. The reference is listed as (java frame), which I know has something to do with threading. When I expand the tree for this node, it opens up and shows <no references>. So it seems pretty clear that this is not a reference I'm keeping open, but something internal to Java.

The GC Root object listed in jvisualvm is of type AnalyticNode extends Node which in turn is Node implements Runnable. This root object in no way has anything to do with AWT, Swing, or any heavyweight user interface components, despite the word "frame" being used. In this case, the word "frame" refers to threading.

So does Java keep a reference to the last Runnable somewhere that would be holding this open? Is there any way that I can tell Java to release this reference so it can be properly garbage collected for my heap dump?

What's going on here?

Erick Robertson
  • 32,125
  • 13
  • 69
  • 98
  • In the "Instances" panel, can you select the instance you believe should have been collected, right-click, and select "Show in Threads" from the context menu? If so, what does it say? – erickson Oct 27 '11 at 21:28

2 Answers2

7

In this context, "frame" refers to a stack frame. It sounds like this Runnable, instead of (or in addition to) being the target of a running thread, is stored in a local variable in a frame on the stack of an executing thread. It will be eligible for collection when the method associated with the frame returns.

Based on subsequent comments, my guess is that in your custom thread pool, there's a local variable to which the Runnable is assigned. It's probably in too large a scope (outside a loop) and is not being cleared (assigned null) after each iteration of the loop.

I can reproduce a situation that matches what is described with code like this in a worker thread:

Runnable target = null;
while (true) {
  target = queue.take();
  target.run();
}

Cleaning up the declaration of target so that it is inside the loop fixes the problem.

I'd suggest switching to an Executor implementation from core Java, or posting the relevant code of your custom thread pool if you want to fix it.

erickson
  • 265,237
  • 58
  • 395
  • 493
  • @ErickRobertson Are you using an `Executor` from JSE? Which implementation class? – erickson Oct 27 '11 at 18:19
  • If this was stored in a local variable in a Java core class, wouldn't that show up in the jvisualvm heap dump? Every other object in the system has a full list of all its references in the heap. So I can only assume that any reference to this object is from somewhere outside of the heap. – Erick Robertson Oct 27 '11 at 18:20
  • Bingo! It wasn't quite the same pattern, but this is exactly what was going on. The reference was in the thread stack in a local variable which was still being held when the thread was waiting for another `Runnable`. Thanks for the great answer! – Erick Robertson Oct 28 '11 at 18:05
  • By the way, I'm also going to look at the `Executor` service. When I first looked at it, I was completely overwhelmed by it, and I didn't need most of its features. Now that I look at it, it seems pretty straightforward. It seems only a couple lines of code to swap and test it, so it's on my list of background projects. It will be easy enough to benchmark it both ways and determine the better-performing solution. Thanks again for your help and learnings. – Erick Robertson Oct 28 '11 at 18:18
1

What did you do with the object you created? Did you create a thread and point it to it? In that case you must make sure the thread has been stopped by allowing the code in run() to finish running.

Sarel Botha
  • 12,419
  • 7
  • 54
  • 59
  • The object is given to a thread pool whenever it has work that needs to be done. In the state in which I had thread dumped, the object has been fully un-referenced and the thread pool is idle. There are no remaining references in code to this object. Could the last thread that ran it be keeping some internal reference to the last runnable it ran? – Erick Robertson Oct 27 '11 at 18:13
  • That's certainly possible. Of course it shouldn't. As an experiment what if you make a wrapper Runnable which just delegates to your real Runnable and you manually remove the reference in the wrapper runnable to your real runnable? Does your runnable get GCed and the wrapper remain? – Sarel Botha Oct 27 '11 at 18:33
  • Also, what happens if you stop the executor and what happens if you have it execute another runnable? Does this one get released? – Sarel Botha Oct 27 '11 at 18:55