4

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.

yas4891
  • 4,774
  • 3
  • 34
  • 55

2 Answers2

3

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.

chill
  • 16,470
  • 2
  • 40
  • 44
  • *going out of the scope means that the local variable is no longer part of the root set for garbage collection.* this is not correct, an object is consider garbage material when it's actually unused any more, i.e. when there are no more references to. for example `{Object a=new Object(); a.hashCode(); //provided there are no more references to a it's garbage material }`. – bestsss Nov 19 '11 at 20:13
  • @bestsss, perhaps you wanted to say something else, because in this form your comment does not make much sense ? – chill Nov 19 '11 at 23:35
  • JVM doesn't understand scope as Java defines it. brackets {} do not define scope even in bytecode, there are 'frames', indeed, but they are not aking to scope. In the previous comment even if infinite loop exist after `a.hashCode()` the GC is free to collect 'a' provided it's not referred any more. As for the edit: the JVM is not required to collect anything at all, and there can be a JVM w/o any garbage collector. – bestsss Nov 20 '11 at 14:03
0

The very simple answer is b/c is inefficient.

There are many garbage collector algorithms and some may aggressively collect. Some compilers do allocation on the stack but the most obvious in your case is: doSomething() may actually keep (leak) a reference to the object elsewhere.

bestsss
  • 11,796
  • 3
  • 53
  • 63