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
John Pritchard<br />If a JTree falls in the woods, is it Observable
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
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.
Joined: Oct 23, 2002
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
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.
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 ]
SCJP 1.4 100% @ Peking, China <br />~~~~~~~~~~~~~~~~~~~~~<br />但使龙城飞将在, 不教胡马度阴山!
Joined: Jun 17, 2002
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.
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?
Joined: Jul 03, 2001
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.
Joined: Mar 28, 2002
Thanks Jose - that puts a lot more light on the subject.