Win a copy of Learn Spring Security (video course) this week in the Spring forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

GC questions

 
Frank Zheng
Ranch Hand
Posts: 76
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
HI,
A question about GC.
Say I have the following code:
void aMethod(){
VeryLargeObject x=new VeryLargeObject();
// do sth. here
x=null; // Is it better off to set this x to null at the end of
// the method or better let GC to deal with it.
}
Thanks,
Frank
 
Ian Darwin
author
Ranch Hand
Posts: 64
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Frank Zheng:
HI,
A question about GC.
Say I have the following code:
<pre>
void aMethod(){
VeryLargeObject x=new VeryLargeObject();
// do sth. here
x=null; // Is it better off to set this x to null at the end of
// the method or better let GC to deal with it?

}
</pre>

There is no difference between the two alternatives you suggest. An object that is declared within a method, and whose reference is not passed anywhere outside that reference, is automatically eligible for GC when the method returns, since the only reference to it is a local, and locals are discarded when a method returns.


The notion of assigning null to a reference to make it eligible for GC comes from long-running methods, such as main().


"Eligible for GC" means it will be freed up the next time the garbage collector runs, which will be "some time later" (as determined by the Java runtime code).


A good reference to memory leaks is this article by Ethan Henry of Sitraka (formerly KL Group), which you can read at DDJ.com.

------------------
Ian Darwin,
Author of Java Cookbook: Solutions and Examples for Java Developers
[This message has been edited by Ian Darwin (edited September 25, 2001).]
 
Peter Tran
Bartender
Posts: 783
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Frank,
Personally, I think it's a good habit to set any object references to null one you're done using it for the following reason. Within the method, if you're allocating some pretty expensive objects, it's good to set the object reference to null once you're done and especially if your method is a really long one. If your program is running low on memory and the GC thread kicks in, it will collect the memory for that object eventhough you have *NOT* returned from the method; otherwise, the object will not get GC'ed, and you may run out of memory.
Try the following program. I ran it on W2K using JDK 1.3.1_01. Of course, this behavior isn't guranteed across all JVM implementation.

The output I get is:
[/code]
First set ...
new foo1
new foo2
new foo3
new foo4
new foo5
Calling GC ...
GC'ed foo5
GC'ed foo1
GC'ed foo3
[/code]
-Peter

[This message has been edited by Peter Tran (edited September 26, 2001).]
 
Andrew Ao
Greenhorn
Posts: 16
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
i would like to make a short note that nullification should be used with stack, or similar situation. otherwise, it could cause memory leak from time to time.
regards,
-aao
 
Peter Tran
Bartender
Posts: 783
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Andrew,
Again, this is only critical if the collections is an instance variable of the class. If the collection (e.g. stack) is local to the method, then it's not a hard requirement to set the reference variable to null. Once the method returns, the JVM GC thread is smart enough to GC the object. If your collection is a class instance variable, you're probably doing some caching or holding on the object reference for a reason anyway.
-Peter
 
Frank Zheng
Ranch Hand
Posts: 76
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for your reply. I have a btter understanding of this issue now. Any idea about the reference counting? I 'd like to have a basic know-how about it. Any resources about this is also appreciated.
Thanks again!!!
 
mitchner green
Greenhorn
Posts: 21
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
A good resource for this is "Effective Java" by Joshua Bloch. He has a chapter describing exactly how you get a memory leak in Java when building a simple stack. It's interesting.
In general, I don't think it's a good idea to set object references to null, except in special situations (like the stack implementation above, or maybe if the object is huge). The best way to not hog memory is to always keep your variable scope as small as possible.
Before I'd clutter my code with a bunch of object=null, I'd need a really good reason to do so.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic