"finally" how effective is it for garbage collector ?

Question

I am a Java Developer and a SCJP2 with 99% score. Recently, I was in a debate with one of my colleague over the use of }try { //code } finally{}" for helping in the garbage collection of method level objects. For e.g. consider the following code.
////// code starts //////////
public class TestFinallyGC {
public void aMethod() {
java.util.ArrayList myList = null ;
try {
myList = new java.util.ArrayList();
// do something with the list
} finally {
myList = null;
////// code ends //////////
Now, my question is : How effective is or useful is the above finally block in above code for the garbage collection of the ArrayList object ? Because if the "finally" block is always going to be at the end of the method then by the time the method finishes (and the finally block also executes at around same time) the variable "myList" will also go out-of-scope and the object it was representing becomes eligible for garbage collection, no matter whether we explicitly set it to "null" or not.
Is the above conslusion correct ?
--Vinod.

Answer 1

How did you decide that references on the stackwere
not reachable?Personally I decided it because after I exit a block
or return from a function, the variables defined there
go irreversibly out of scope, so there is no way for
me to ever interact with them again. And since those
where the only references to the large arrays, they
were unreachable and eligible for garbage collection.
Ok. But something owns the stack. At the something is not going out of scope. It still owns the stack.
Given that reachable does not just
mean user threads but JVM threads as well.I did not create any threads, so there is just the
"Main" thread.
As far as I know there are no JVM threads. That is to
say, I read the JLS and did not find their existence
defined there. It does say that finalizers may be run
on "any thread" but does not say that there must be a
separate finalizer thread. Yes as far as you know. However, none of the specs disallow the JVM from creating JVM threads. The spec is specific that it unreachable from a thread, but it does not specify how those threads come into existence.
Basically since the jls
does not say there are JVM threads, we must assume
that if they exist then the behavior would be the same
as if they did not.
No. That is not the way one should approach a spec. Anything that the spec does not specify must be considered to be undefined. It can have any possible behavior.
So the stack might belong to a java object/thread or it might not. Either is possible. If it doesn't then it is unreachable and thus collectible. If it does then it is not.
So both suppositions are equally valid. So presumably the answer to my question would have been that you are assuming that it does not belong to a java object.
(Naturally we are both aware that the stack is always reachable by the system. It is not a temporary. Thus the question is only if it belongs to a java object or not. Or possibly if it does belong to a java object then whether references on it are cleared after a method exit.)
And as far
as I know there is no reason to think that thestack
might not be in the java domain space (althoughthat
might suggest a chicken and egg problem.)??
What are you talking about? What is the "java domain
space"? I don't know what that means.
JVMs always consist of C/C++ code with some mixture of Java. There is always C/C++ and there is always java. The first is true because the OS will not run java byte codes. The second is true because the JVM must always load java.lang.String.
Given this, it means that in any JVM there will be a domain space that consists of java entities and a domain space that consists of something else (C/C++.)
The question here is whether the stack is part of the C/C++ space or part of the java space.
The only stack I know about is the one that starts at
Thread.run() and goes up through all the methods that
have been called, ending at the method currently
executing. There is nothing above or below the stack.
When you call a method, its size increases by one,
and when a method returns, the size decreases by
one.
Doubt it. The stack pointer might move but I doubt the stack size increases and decreases. There are performance reasons for not doing that along with system management problems.
Of course if you have a reference that states otherwise then I would be glad to read it.
I think the whole point of this discussion is "what
happens to the stack frames that are lost when methods
return". My answer: They cease to exist, any
references they may have contained are lost and if
they were the only references to a given object it
would be immediately available for garbage
collection.