Win a copy of Functional Reactive Programming this week in the Other Languages forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Garbage Collection of Objects in a for loop

 
John Pritchard
Ranch Hand
Posts: 49
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi All-
Relatively new to the site and just started the exam prep about a month ago. I have garbage collection fairly well down ( I say that now), but I am struggling with the following obstensibly simply snippet.
Given the following method:


How many objects are eligible for Garbage Collection once the method completes?
Are they all eligible since the are within the for loop scope only?
Are non eligible b/c all the string objects are cached?
hrmph?!
-jOhn
 
Sudd Ghosh
Ranch Hand
Posts: 191
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
According to me, it should be count-1, ie, all objects locally created inside the for loop should be garbage collected if you are not saving the reference into some outer-scope variable. However, some mock exam said it is count-2, implying that the last Object "temp" will not be garbage collected. But I still don't know why it should be that way.
Thanks, Sudd
 
Vin Kris
Ranch Hand
Posts: 154
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The question explicitly states "at the end of the method". Therefore the objects eligible for GC is equal to (count-1) in this case.
String literals (& also String objects interned) are not GC'ed. Here, every iteration of the for loop creates a new String object from the heap. These objects are eligible for GC as other objects created on the heap.
The answer to this question, according to some mocks, would be (count-2) at the end of the for loop.
Please read the 2nd half of the discussion here. I have tried to explain the GC behaviour of descoped objects - though it is not required for the exam.
 
Sudd Ghosh
Ranch Hand
Posts: 191
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Vin -
Thanks for the nice link. It really helped in clearing "some" doubts. However, I still don't fully understand why Java had to behave this way ??
Thanks, Sudd
 
Jose Botella
Ranch Hand
Posts: 2120
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sudd, Having the JVM to nullify each variable right after they fall out scope will imply more work that has not been judged necessary.
Anyway it depends on the implementation, because I have seen a post that showed the JVM reutilizing a descoped local variable for assigning a new one; however a different type of descoped local variable was left alone. Obviously, Java programmers are not required to know the exact policy a given JVM follows respect to descoped local variables. But they are advised to set to null descoped local variables if the object pointed to needs to be eligible for g.c. and the method will take a long time to finish yet.
 
Keen Chen
Ranch Hand
Posts: 47
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sorry... i dont' think so.
neither count-1 nor count-2.

Object temp = " Hello "+i;
1. " Hello " was been put into String pool, only one object.
// object created in the loop
2. i -> new Integer(i).toString() : two objects ,and concat, so there objects.
3. temp: the 2th step returns, no new object

so, every iteration, there are 3 objects were created. so , i think ,the number =(count-1)*3 + 1.
best rgrds
Keen Chen
[ November 25, 2002: Message edited by: Keen Chen ]
[ November 25, 2002: Message edited by: Keen Chen ]
 
Vin Kris
Ranch Hand
Posts: 154
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You are right keen, thats a very good point. I'm embarassed that I missed the obvious.
But I differ with your answer though. I'd say the answer is either (count-1)*2 or (count-2)*2.
In every iteration of the for loop, 2 objects are created.
1) StringBuffer object - for doing stringbuffer.append(" Hello ").append(i)
2) String object - from stringbuffer.toString();
How the Hotspot JVM is going to compile this at runtime, I have no idea.
 
Jose Botella
Ranch Hand
Posts: 2120
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Use javap -c
to see:
 
dragon ji
Ranch Hand
Posts: 110
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
so,what's the correct answer?please...
 
Jose Botella
Ranch Hand
Posts: 2120
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
After the method ends only the String object "Hello" is not eligible for garbage collection.
 
John Pritchard
Ranch Hand
Posts: 49
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Good thread. Thanks all for the input.
 
Ali Macky
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Consider the following example

The result of the above:
 Both are equal
Therefore I concluded that none of the objects from that loop are eligible for garbage collection since what we will have is a literal string for each iteration of the loop.
Am I correct?
 
Jose Botella
Ranch Hand
Posts: 2120
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The point in the example of the loop was that the new string object are:
a) computed at runtime because i is changing at runtime. Strings objects computed at runtime are not automatically interned.
b) reassigned to the same variable in each iteration, and thus, made eligible for g.c.
In your example the content of both string objects is known at compile time. The compiler will produce the same reference for them. The JVM will create only one string object.
 
Ali Macky
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Jose - that puts a lot more light on the subject.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic