GC Question from Exam Cram Page 163

[Govinda Agarwal]

Question : Here is a method that crates a number of String objects in the course of printing a sequence:
1.public void countDown()
2.{
3.for (int i=10;1>=0;i--)
4.{
5.String tmp = Integer.toString(i);
6.System.out.println(tmp);
7.}
8.System.out.println("BOOM!");
9.}
When the program reaches line 8 , how many of the String objects created in line 5 are
eligible for garbage collection?(Assume that the System.out object is not keeping a reference.
The answer given in the book is 10 .
I have a doubt over it . I think it should be 11.
Please help.

[Anonymous]

10 string objects are created in the heap. One local variable of String is created on stack. When the loop terminated, tmp goes out of scope automatically and is not longer alive.
So, we are left with just 10 string objects that are not referenced by any variable and hence only 10 are eligible for GC.
Please let me know if my reasoning is inccorect.
-sampaths77 :-)

[srikrish]

I don't know if it's a typo or not but the condition in your for statement checks for 1>=0 (not i>=0). This is always true and so it will be an infinite loop.
[This message has been edited by srikrish (edited September 13, 2000).]

[srikrish]

Also, assuming the condition checks for i>=0, then aren't 11 objects created in the heap by the loop? (i=0 is also included in the loop). So, my answer in that case would be 11. Any thoughts?

[Mapraputa Is]

similar question was discussed on http://www.javaranch.com/ubb/Forum24/HTML/000038.html

[srikrish]

Thanks Mapraputa Is.

[J. Macha]

I agree that there are 11 string objects created and thus when the loop exits and tmp goes out of scope then 11 String objects should be ready for GC.
I am a little confused by the explination about 10 of the objects being on the heap and the 11th being on the stack.

[William Brogden]

Easily my most troublsome question. There is an extended discussion at: http://www.lanw.com/java/localvariables.htm
Short form:
I thought that because the reference to the local variable tmp is kept on the stack, and the GC mechanism checks all Thread stacks for variables, that the reference would still be considered live even outside the loop. It turns out that Java 1.02 compilers were not smart enough to optimize this, but Java 1.2 compilers do something to make the 11th object collectable.
So - don't worry about it, you won't get any question on the real exam that is as weird as this.
Bill

[Jim Goodwin]

Bill Brogden,
It seems to me there are two well-formed questions that can be asked here. (1) When does a value become eligible for GC, according to the language specification; & (2) when does it become vulnerable to actually being GC'd in a particular implementation?
I would say (1) that the 11:th string is clearly and unambiguously eligible for GC under the spec. It is no longer reachable by the program; therefore it's garbage.
To put it another way, an implementation that *does* collect the 11:th string at the indicated place ("BOOM") is clearly not incorrect in doing so; therefore, the value is eligible.
But(2) is only meaningful with reference to a particular implementation. To me, this is analogous to asking whether the 11:th string WILL be garbage collected at any given point: it's part of the point of the design that you aren't supposed to ask that question, and the language is not supposed to reveal the answer by its behavior, precisely in order to reserve freedom of action to the implementors.
Of course we all love to peek beneath the hood anyway, but the point is, one shouldn't be surprised that it varies from one implementation to another.

jim