Question

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?

Answer 1

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.