When a variable goes out of scope in Java, is it immediately removed from the stack ?

[daudiam]

When a variable goes out of scope in Java, is it immediately removed from stack and one strong reference to the object it pointed to removed ?

[JamesCherrill]

If I understand the question, then the answer is "yes", but why do you ask, and what do you want to infer from the answer?

[daudiam]

Thanks. I was reading about the Reference class in java and I came across this code

while (rslt.next())
{
    rowCount++;
    List<Object> row = new ArrayList<Object>(colCount);
    for (int ii = 1 ; ii <= colCount ; ii++)
        row.add(rslt.getObject(ii));

    List<List<Object>> results = ref.get();
    if (results == null)
        throw new TooManyResultsException(rowCount);
    else
        results.add(row);
    results = null;
}

Then, the author said "The language spec says nothing about the JVM being required to clear variables that go out of scope, and in fact the Sun JVM does not do so. If we didn't explicitly clear the results variable, it would remain a strong reference throughout the loop".

When a variable goes out of scope, if the object it referred to didn't have any other strong reference, then the object will be up for garbage collection, whether or not its cleared to null.

Secondly, I can't see results going out of scope during the loop.

[HarryPad]

Most likely, most VMs will wait until a method goes out of scope to reset the stack frame - and thus you will have references that are out of scope but still on the stack. - but again this is up the VM writers.

Now the object being referenced may be marked ok for garbage collection, that has to wait for the garbage collector to run. And many times with shorter running programs this never happens and the entire memory space is returned to the OS at once when the program terminates

[JamesCherrill]

It seems to me that the variable results is declared in the scope of the while {...} block, and will remain in scope until the while loop is exited. At this point it beomes impossible to use that variable in any more code, so the question of exactly when its memory becomes free is an implementation detail irrelevant to the correct execution of the program. Similarly, if this is the last remaining strong reference to some object the object will subsequently become eligible for garbage collection, but since that says nothing about exactly when it will be garbage collected, that's also an irrelevant implementation detail.
As for "clearing the variable": setting it to null, if it was the last strong reference to some object, the object will subsequently ... (as above), regardless of any scope issues.

[NormR1]

Another point of view:
Scope is a compile time concept.
Stack is a runtime concept.

[daudiam]

Thanks. I think I get that part. But regarding the code that I posted and the author's comments, I can't understand what's the insistence on clearing the variable. Isn't it that once the variable is out of scope, it is eligible for garbage collection, whether or not it was cleared ? Also, in the code, I don't see "results" going out of scope.

[JamesCherrill]

Local variables do not get garbage collected. They are allocated on the stack and thus automatically lost when the block is exited (the block in this case being the while {...}). The objects to which the variable refers are not on the stack, and are eligible for GC when there are no longer any (strong) references to them.

Sun says:
14.4.2 Scope of Local Variable Declarations
The scope of a local variable declaration in a block (§14.2) is the rest of the block in which the declaration appear.

Thus the scope of this variable is from line 8 to line 14
Contrary to my over-simplified earlier post, when the execution returns to line 2 as part of the looping, the variable is out of scope, and any reference it may have held is no longer valid.
QED I belive the nulling on line 13 is redundant.

[daudiam]

Thanks. It means that results goes in and out of scope repeatedly while the loop is in progress ? When the author says that the JVM doesn't require variables to be cleared when they go out of scope, he means that when the control returns to the starting of line 8 (and "results" re-enters its scope), by virtue of "results" still holding its reference, the strong reference to that object is revived (though, it doesn't remain revived for long, as its replaced by another reference in line 8 itself, so line 13 also proves redundant in this way). Am I right ?

[JamesCherrill]

This is a kind of non-question. results cannot be accessed before line 8, so whether or not there is still a little block of memory allocated to it there is irrelevant. At line 8 it's declared, so its value is given by the initialisation expression (or is null if there isn't one), so any hypothetical previous value is lost before you can use the variable again (in lines 9-14).
If the reference were "revived", that would be a definite violation of the language definition, and a serious bug.
Similarly, it's irrelevant exactly when the reference counter gets decremented because there is no guarantee about when the un-referenced object may get GCed; it's just "some time later". Either way, you can't access it any more.
I just think your code's author is wrong. Line 13 is redundant in that particular case (but, for example, if results were declared as an instance variable of the class, line 13 would be useful)

[daudiam]

Yeah. Thanks for clearing it.