"Lew" <lew@lewscanon.com> wrote in message
news:3pqdne81S7ZGsjzanZ2dnUVZ_tWtnZ2d@comcast.com...
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 issue was discussed on this thread
http://groups.google.com/group/comp.lang.java.programmer/browse_frm/thread/72441692bb623f62/0fdda2bb6c377cec#0fdda2bb6c377cec
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.
Quoting from _Effective Java_:
It should be noted that on present-day JVM implementations, it is not
sufficient to exit the block in which a variable is defined; one must exit
the containing method in order for the reference to vanish.