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

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 2

Not in this case. myLocalVar falls out of scope as soon as the function returns, so setting the reference to null does absolutely nothing.

Answer 3

As you correctly point out, nulling out in this case is totally pointless.

Back on JDK1.3 I did actually have a case with an extremely large object graph that also contained lots of circular references within the graph. Clearing out a few of the references did actually improve GC times quite noticeably.

I am not sure if this would apply with a modern VM. Garbage collectors have become increasingly smarter.

Answer 4

The Java GC is supposed to be "sound" but is not necessarily immediately "complete". In other words, it is designed so that it would never eliminate objects that are still accessible by at least one path (and thus cause a dangling reference). It is not necessarily immediately complete since it might take time until it removes everything that can be removed.

I think that most GC myths come from a misunderstanding of that concept. Many people keep too many instance variables alive, and that causes problems, but that is of course not the issue here.

Other people put the local variables in an instance variable (e.g., by passing it to function), and then think that nullifying the local variable somehow eliminates the variable, which is of course untrue.

Finally, there are people who overrely on the GC and think it would do functional shutdown for them (E.g., close connections when variable is removed) which is of course not the case. I think the source of this line is the "I'm really really done with it but I'm not sure how to ensure that".

So yeah, you're correct that it's unneccessary.

Answer 5

To the best of my knowledge, nulling a variable immediately before it leaves the scope makes no difference to the garbage collector.

Of course there are cases where it indeed does help. E.g. when var is not a local variable but a member or static member. Then destroying the reference might make the object unreachable and thus eligible for collection.

Another case where it might help even with local variables if a function allocates much temporary memory to initialise some data for further processing and can throw away all references to the temporary memory before beginning the processing:

SomeResult SomeFunction(SomeClass param) {
    TempData big = new TempData(param);
    IntermediateResult intermediate = big.GetIntermediateResult();
    big = null; // allow GC to reclaim the memory before returning from the function
    intermediate.FurtherProcessing();
    return intermediate.EvenMoreProcessing();
}

Answer 6

I don't know the technical details, but as far as I can remember, the variable is nothing more than reference from the current stack frame, and until this reference is removed, the object cannot be garbage collected. Now, but explicitly setting it to null, you've made sure that the reference is gone. If you don't you're basically letting the VM decide when this reference is cleared, which might or might not be upon exiting the scope (unlike C++, if the object is located on the stack and MUST be destroyed). It might be when the stack frame is overwritten with the next. I'm not sure if there's actually a VM which does this.

Short answer though, it's unnecessary, the mark and sweep will get it eventually. It's at most a question of time.

Answer 7

In some circumstances, it can be useful to null variables (usually instance or class variables). But nulling a local variable immediately before the end of the method does absolutely nothing.

When you set a variable to null, you are merely removing that reference to the actual object. But when a local variable goes out of scope, the reference is removed anyway; therefore, setting it to null as the last line of the method is simply redundant.

Answer 8

If your class hangs around for a long time, then nulling out objects it references will allow them to be collected.

This is almost never an issue, most times nulling objects is not useful.

When you think of object allocation and freeing, pay attention to the things that the "System" has handles to: Active threads, windows that haven't been dispose()d, and one or two more things but I can't remember right now.

Every object in your system "Hangs" off these mount points in a giant upside-down tree. If you cut any branch free from these "Roots" the entire branch falls to the ground and is collected by the Lawn Mower of Garbage Collecting.

Most classes need all their member variables for their entire lifecycle--and when their life is finished, their entire branch is trimmed including all their members; hence--no need to null.

(these trims, by the way, are quite efficient, even more than C++'s free since they don't require touching each object as it's freed)

Answer 9

You are correct. Nulling out a variable that will immediately fall out of scope anyway is unnecessary and makes no difference whatsoever to GC. All it does is clutter the code. In Effective Java 2nd Edition, the author recommends against unnecessary nulling out of local variables. See Effective Java, 2nd Edition, Item 6: Eliminate obsolete object references, for a full writeup.

You can also see this in the article Creating and Destroying Java Objects, at InformIT. Read the entire article to find the place where Joshua Bloch agrees with you.

When a local variable falls out of scope, it is exactly the same as if you null the reference to it.

EDIT: Add link to Effective Java 2nd Edition at Sun website

Answer 10

Another possible factor in this myth is that it can make a difference to null out a local variable if you are done with it before the end of the method. This would allow the GC to collect that object before the method is complete, which could be useful.

Someone might have been given that advice at some point and misunderstood it as a need to always null out the local variables.

Answer 11

There are only two cases where I have found setting a variable to null has been useful:

• In unit tests which create a large object in a field. The unit tester may retain the test object and the objects you created for the life of all the tests. This can cause the tester to run out of memory. In this case it is often better to use local variables instead of fields, but if a field required it can be cleared in the tearDown.
• Circular references can be cleaned up by the GC but not with a simple incremental collection. This can mean that objects with circular references take more work to clear and can live much long than they would otherwise. Generally this doesn't matter but if you are trying to reduce your full GC time, it can help to break circular references.

Answer 12

Java Platform Performance describes a situation where nulling a local variable which dropped out of scope actually had an effect on the GC.

However, the paper refers to a very old version of java. As mentioned in this question, this no longer affects current JVM implementations.

Answer 13

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)

Answer 14

If you don't need large objects in your local scope anymore, you can give the JVM a hint and set the reference NULL.

public void foobar()
{
    List<SomeObject> dataList = new ArrayList<SomeObject>();

    // heavy computation here where objects are added to dataList 
    // and the list grows, maybe you will sort the list and
    // you just need the first element... 

    SomeObject smallest = dataList.get(0);

    // more heavy computation will follow, where dataList is never used again
    // so give the JVM a hint to drop it on its on discretion
    dataList = null;

    // ok, do your stuff other heavy stuff here... maybe you even need the 
    // memory that was occupied by dataList before... 

    // end of game and the JVM will take care of everything, no hints needed
}

But it does not make sense before the return, because this is done by the JVM automatically. So I agree with all postings before.

Answer 15

Not only is nulling a local variable like that meaningless in terms of GC, it may cause unnecessary loading of the variable into a register in order to null it out, which makes the situation worse. Imagine if there is 1000 lines of code between the last read or write to myLocalVar, and then you reference it just to null out the reference. The value is long gone from the register, but you have to load it back in to memory to work with it.