Question

I just read this article: The Truth About Garbage Collection

In section “A.3.3 Invisible” it is explained how and when an object gets into the invisible state.

In the below code, the object assigned to the variable foo will become invisible after leaving the try/catch block and will remainly strongly referenced until the run method exits (which will never happen, because the while loop runs forever).

public void run() {
    try {
        Object foo = new Object();
        foo.doSomething();
    } catch (Exception e) {
        // whatever
    }
    while (true) { // do stuff } // loop forever
}

It is stated in this article:

However, an efficient implementation of the JVM is unlikely to zero
the reference when it goes out of scope.

Why is that not efficient?

My attempt at an explanation is as follows:

Say the stack for this method contains four elements, with the now invisible object being at the bottom.
If you want to collect the object instantly, you would have to pop and store three elements, pop and discard the fourth element and then push the three still valid elements back onto the stack.
If you collect the invisible object after control flow has left the run method, the VM could simply pop all four elements and discard them.

Answer 1

The local variables are not on the operand stack, but in the local variables area in the activation frame, accessed, in the case of references via aload and astore bytecodes and zeroing a local variable does not involve any pushing and popping.

Zeroing is inefficient because it is not needed:

• it would not cause an immediate garbage collection cycle
• the zero may soon be overwritten by another value as dictated by the logic of the program.
• going out of the scope means that the local variable is no longer part of the root set for garbage collection. As such what value it held immediately before going out of scope – zero or a valid reference – is immaterial; it won’t be examined anyway.

EDIT:

Some comments on the last statement.

Indeed, at a bytecode level there are no scopes and a local variable slot may remain a part of the root set until the method returns. Of course, a JVM implementation can determine when a local variable slot is dead (i.e. all possible paths to method return either don’t access the variable or are stores) and don’t consider it a part of the root set, but it is by no means required to do so.