Does it help GC to null local variables in Java

Question

I was 'forced' to add myLocalVar = null; statement into finally clause just before leaving method. Reason is to help GC. I was told I will get SMS's during night when server crashes next time, so I better did it :-).

I think this is pointless, as myLocalVar is scoped to method, and will be 'lost' as soon as method exits. Extra nulling just pollutes the code, but is harmless otherwise.

My question is, where does this myth about helping GC come from? (I was referred to "Java memory books") Do you know any article from 'authorities' which explain it in more depth? Is there possibility this is not a myth, but really helps somehow? If so, how? May nulling local variables cause any harm?

To clarify, method look like this:

void method() {
  MyClass myLocalVar = null;
  try {
    myLocalVar = get reference to object;
    ... do more here ...
  } finally {
    if (myLocalVar != null) {
      myLocalVar.close(); // it is resource which we should close
    }

    myLocalVar = null; // THIS IS THE LINE I AM TALKING ABOUT
  }
}

Answer 1

There was an old piece of Sun documentation, Java Platform Performance (link sadly now broken, and I haven't been able to find a new one), which described a situation where nulling a local variable which dropped out of scope actually had an effect on the GC.

However, the paper referred to a very old version of java. As mentioned in this question (which also contains a précis of the problem described in the paper), this no longer affects current JVM implementations.

Answer 2

That is a myth that goes way back to when java first came out and C++ guys didn't trust the gc.

The gc knows what it is doing. nulling out var wont hurt anything, but it wont really help anything either. Jeff had a pretty funny post on this just the other day.

Answer 3

Nulling local variables can indeed help in some edge cases. This doesn't apply to situation in original question, but is educational anyway... Let's consider this program:

public class Main {
    public static void main(String[] args) {
       {
           Main local = new Main();

           // inner = null;
       }

       while (true) {
           // long running method
       }
    }
}

If inner = null; is commented out, object in local variable cannot be garbage-collected during while loop. Reason is that Java Virtual Machine doesn't know about scopes like this. All it has is:

D:\workspaces\workspace-3.4\test\src>javap -verbose -c Main
public class Main extends java.lang.Object
  minor version: 0
  major version: 50
  Constant pool:
const #1 = Method       #4.#11; //  java/lang/Object."<init>":()V
const #2 = class        #12;    //  Main
const #3 = Method       #2.#11; //  Main."<init>":()V
const #4 = class        #13;    //  java/lang/Object
const #5 = Asciz        <init>;
const #6 = Asciz        ()V;
const #7 = Asciz        Code;
const #8 = Asciz        main;
const #9 = Asciz        ([Ljava/lang/String;)V;
const #10 = Asciz       StackMapTable;
const #11 = NameAndType #5:#6;//  "<init>":()V
const #12 = Asciz       Main;
const #13 = Asciz       java/lang/Object;

{
public Main();
  Code:
   Stack=1, Locals=1, Args_size=1
   0:   aload_0
   1:   invokespecial   #1; //Method java/lang/Object."<init>":()V
   4:   return

public static void main(java.lang.String[]);
  Code:
   Stack=2, Locals=2, Args_size=1
   0:   new     #2; //class Main
   3:   dup
   4:   invokespecial   #3; //Method "<init>":()V
   7:   astore_1
   8:   goto    8
  StackMapTable: number_of_entries = 1
   frame_type = 8 /* same */

}

There is no information about scope of local variable. So from JVM's point of view, above program is equivalent to:

public class Main
{

    public Main() { }

    public static void main(String args[])
    {
        Main main1 = new Main();
        do
            ;
        while(true);
    }
}

(Generated by JAD decompiler)

Conclusion: there IS some rationale in nulling local variables in very special cases like this. But if method is going to finish soon (like in my original question), it doesn't help.

This was inspired by comment from Zdenek Tronicek on java-cz mailing list (in czech language, sorry)