gc yet again!

[Anshuman Acharya]

check this code:
public void down(){
for(int i = 10; i>= 0; i--){
String temp = Integer.toString(i);
}
//here
}
it asks how many objects areeligible for gc at //here....
the answer is 10 and not 11? i can't figure out why.... temp's scope has finished at //here right?

[Manfred Leonhardt]

Hi Anshuman,
Don't confuse scope with garbage collection. If we use scope we should get 12 not 11 (forgot about i didn't you!).
Garbage collection doesn't care about scope. It looks to see if a reference exists to a memory location. If not then it frees the memory. In this case we create 11 items using a single reference. When the loop is done we have 10 objects in memory without references to them. The variable 'temp' still points to the 11th item. Also 'i' still points to a valid memory location.
Variables created in methods are normally alive until the method has completed. The exception to that is if we set the variables to 'null' in the method.
Regards,
Manfred.

[Anshuman Acharya]

got it manfred! actually i was not confusing scope with gc. i was confusing scope with method closure!
thanx

[Peter Tran]

Manfred,
From Anshuman example, the variable "i" doesn't exist outside the for() loop. The scope of the variable "i" is only valid inside the for() block.
I think the answer is 11, because the "temp" variable isn't valid outside the for loop either. To test my theory, I wrote the following program.

class foo {
    int i;
    foo(int i) {
        this.i = i;
    }
    public void finalize() {
        System.out.println("finalize called on foo("+i+")");
    }
} // class foo
public class ex {
    public static void main(String args[]){
        for (int i = 10; i >= 0 ; i--) {
            foo f = new foo(i);
        }
        // Call GC a bunch of time and hopefully the
        // JVM gets the hint!   [img]http://www.javaranch.com/ubb/biggrin.gif[/img]
        System.gc();
        System.gc();
        System.gc();
        System.gc();
        System.gc();
        System.gc();
        System.gc();
        System.gc();
        System.gc();
        System.gc();
        System.gc();
        System.gc();
        System.gc();
    } // main()
} // class ex

Here's the output:

D:\Work>javac ex.java
D:\Work>java ex
finalize called on foo(10)
finalize called on foo(9)
finalize called on foo(8)
finalize called on foo(7)
finalize called on foo(6)
finalize called on foo(5)
finalize called on foo(4)
finalize called on foo(3)
finalize called on foo(2)
finalize called on foo(1)
finalize called on foo(0)

If temp was still a valid reference, then the finalize() method wouldn't have been invoke for foo(0).
-Peter

[Peter Tran]

Anshuman,
Which mock exam told you the answer is 10?
-Peter

[Anshuman Acharya]

so we're at it again huh? i thought i was right then when i said 11. i will try to trace back the mock exam where i got this.
all i have to say is that it is erratta like this that relly bugs you. i thought i knew how gc worked but this example really threw me off track.
thanks peter for restoring my confidence...

[Anshuman Acharya]

some material from a previous post on this very topic:
http://www.javaranch.com/maha/Discussions/Garbage_Collection/Garbage_Collection_-_JavaRanch_Big_Moose_Saloon.htm

[Peter Tran]

Anshuman,
Reading the other posts, I'm glad to see Bill had the same idea to test out his theory using a similar procedure. It's an interesting point, but overly complex for the certification. I can't see SUN wording a GC question in the same way.
-Peter