Re: general performance question

Mike Schilling wrote:
There's this, which might not be what the OP had in mind:


void method()
{
...
if (condition)
{
LargeObject lg = new LargeObject();
lg.doStuff()
// See discussion below
}
...
}

This has been discussed on this group, and the consensus is that the method's stack frame continues to point to the LargeObject, so that it can't be collected until the method returns. (It seems to me that the JVM should be free to null out the reference once it goes out of scope, or even if it's in scope but flow analysis makes it clear that it can't be used any more, but that was a minority opinion.) Thus it can make sense to replace the comment with

lg = null;

No, actually, it doesn't. This is one of the urban legends of Java.

I don't know of any "consensus" that the variable lingers through the method, nor that it matters much if it does. The HotSpot compiler very well could optimize an allocated object out of existence altogether, at runtime, according to the runtime needs of the program. Variables and objects are different, after all.

AFAIK it's not possible to guarantee the lifetime of an object will last past its syntactic validity. There are all kinds of runtime conditions that could have it vanish anytime after it's dereferenced or out of scope. Setting a variable to null thinking that that will help release it really won't.

Brian Goetz is among the notables who have debunked the "set to null to help GC" myth:
<http://www-128.ibm.com/developerworks/java/library/j-jtp01274.html>
Because allocation and garbage collection at one time imposed significant performance costs on Java programs, many clever tricks were developed to reduce these costs, such as object pooling and nulling. Unfortunately, in many cases these techniques can do more harm than good to your program's performance.
....
Sun warned of this risk and explained how explicit nulling was needed in [certain] cases... . Unfortunately, programmers often take this advice too far, using explicit nulling in the hope of helping the garbage collector. But in most cases, it doesn't help the garbage collector at all, and in some cases, it can actually hurt your program's performance.

Think of it this way - setting a variable to null has nothing to do with the business logic of the program - it's a hack that is based on a superstition relating entirely to implementation. Breaking the logic of your program in order to imagine a performance improvement is a classic programming mistake.

--
Lew
.

Relevant Pages

  • Re: Petition for the removal or voluntary departure of Richard Heathfield from this newsgroup
    ... when A goes out of scope or is reassigned In this case, ... linked list when Root goes out of scope (or perhaps is just assigned ... AFAIK a classic garbage collector periodically stops the app and goes ... running around looking for pointers to heap that are fair game to get ...
    (comp.programming)
  • Re: general performance question
    ... makes a noticeable difference performance-wise? ... with object creation. ... LargeObject lg = new LargeObject; ... scope, or even if it's in scope but flow analysis makes it clear that ...
    (comp.lang.java.programmer)
  • Re: Local variables - quick question
    ... You can't use a variable which isn't in scope within ... possiblity to declare class argument int i - only signal for me is compiler ... > being alive by the garbage collector. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Difference between setting reference=null and going out of scope?
    ... my question is in terms of performance and the garbage collector - ... >> a) letting a variable simply go out of scope ... >> b) explicity setting it to null once I am done with it ... > a live reference. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Garbage collector quiz
    ... >> the out of scope variable tmp prevent the garbage collector from ... > variable count as a VALID reference? ...
    (comp.lang.java.programmer)