how many objects are available for gc?

[Ankur kothari]

this is from whizlabs 1.4

how many string objects are eligible for gc when the program reaches line 8

   
public void countDown()
{
for(int i=10;i>=0;i--)
{
String tmp=Integer.toString(i);//5
System.out.println(tmp);
}
System.out.println("BOOM");//8
}
 

1.0
2.10
3.11
4.none

i think the answer is 11 because 11 objects are created and upon reaching the line 8 all are available for gc since after the for loop the tmp variable is dead

but whizlabs says the answer is 10 since tmp is just out of scope and still has a reference

please explain

[Hiruka Sandev]

Ankur kothari wrote:
when the program reaches line 8

Doesn't this mean line 8 is yet to be executed?

[Ankur kothari]

no....line 8 isnt executed..just forget that line

[rohan yadav]

Of course it will still has reference to tmp, because tmp is just out of scope doesnt necessarily mean it is eligible for gc

[Ankur kothari]

but i think the variable tmp is dead after the loop

[Ankur kothari]

and please go by the // 8 i have given which is the line 8

[Ankur kothari]

so doesnt this mean that no one is referring to the any of the 11 objects(strings)

[Bert Bates]

FYI -

Whenever you see a mock exam question that mixes String objects with GC eligibility, substitute objects with made up type (like MyClass), not String objects. The real exam NEVER mixes these because the String constant pool makes the whole GC topic too muddy.

[Ankur kothari]

ok so what if instead of strings there were MyClass objects....then how many of them would be available for gc after the for loop?

[Punit Singh]

I also think there should be 11 objects available for gc.

[Ankur kothari]

i wished there was a way to find this out....like compiling or running it

[Ankur kothari]

the answer for above would be 11 definitely but this one...will be 10...gc is all about reference variables

  public class And
{
public static void main(String args[])
{
	String tmp="";
	  for(int i=10;i>=0;i--)
{
tmp=Integer.toString(i);//5
//System.out.println(tmp);
}
System.out.println(tmp);//8
} 

}  

[Hiruka Sandev]

See this on invisible objects. According to whats said in that book the 11th object may not be eligible for GC until the method completes.

[Ankur kothari]

this invisible objects topic confused me....the topic above it said that when the method returns it goes out of scope and object can be gc

in invisible objects topic it said that the object will be weakly held even after the block finishes...what is weak and string doing here?

can someone please clear my doubt

[Punit Singh]

Ankur kothari wrote:this invisible objects topic confused me....the topic above it said that when the method returns it goes out of scope and object can be gc

in invisible objects topic it said that the object will be weakly held even after the block finishes...what is weak and string doing here?

can someone please clear my doubt

Actually the topic is saying about method + reference variable placement on the stack.

Actually methods are loaded in the stack, and whatever objects are created in that method those objects' references are also loaded in the same stack with method.

Suppose you have main() method

  
main(){
Object objRef=new Object();
}
  

Then what will happen here.
1. when control enters to main() method. man() is loaded in the stack.
2. Then from new Object() statement, a new Object is created in the heap.
3. objRef reference variable is created on the same stack where main() is loaded.
4. Reference of that new Object() on the heap is stored in objRef reference variable.

Now when you say this:

  
main(){
Object objRef=new Object();
objRef=null;//line1
while(true){
//infinite loop
}
}
  

5. objRef=null; explicitly breaking the link between objRef on the stack and new Object() on the heap.
GC can see that new Object() on the heap is broken. So it can gc it after line 1.

But when this is done

  
main(){
if(true){
Object objRef=new Object();
}//line1
while(true){ //line2
//infinite loop
}
}

here after line1 is executed just scope of objRef local reference variable is over, but we are not breaking the link between objRef and new Object() explicitly. And objRef in not destroyed until main() method returns and stack of main() is destroyed. So till main() is living on the stack, objRef is also living on the stack, but after line1 we cannot use objRef as it is not visible after that, it is called invisible after that.

But it is still residing on the stack and is invisible to us and keeping a reference of new Object() on the heap. Garbage collector can't collect new Object() from the heap as its reference is on the stack.

[Ankur kothari]

hey but can we access the objref referecne outside the if loop? doesnt being able to acess the variable and scope be the same thing?

or do you mean variables are stored only in the stacks with the methods they are in and stay there until the method gets over...or returns

[Punit Singh]

Ankur kothari wrote:hey but can we access the objref referecne outside the if loop? doesnt being able to acess the variable and scope be the same thing?

Ya accessing and scope is the same thing, we cannot access objref outside the if block, but GC is a completely different thing.
Here objref is just marked as not accessible outside the block, it scope status is changed and set to not accessible, but its reference with new Object() in the heap is still alive but not usable by us, so just a memory waste or leak.

or do you mean variables are stored only in the stacks with the methods they are in and stay there until the method gets over...or returns

you are correct here.

[Ankur kothari]

superb punit...thanks a tonne....