Objects eligible for garbage collection

Question

This question was taken from Kathy Sierra SCJP 1.6. How many objects are eligible for garbage collections?

According to Kathy Sierra\'s answer, it is C.

Answer 1

The formally correct answer is that we don't know. And the reason we don't know is this line:

Short story = 200;

This compiles to the following byte code:

CardBoard();
Code:
   0: aload_0
   1: invokespecial #1                  // Method java/lang/Object."<init>":()V
   4: aload_0
   5: sipush        200
   8: invokestatic  #2                  // Method java/lang/Short.valueOf:(S)Ljava/lang/Short;
  11: putfield      #3                  // Field story:Ljava/lang/Short;
  14: return

Line 8 is the key here, Short.valueOf(), which returns a boxed equivalent of the primitive 200. Let's look at the Javadoc of Short.valueOf():

This method will always cache values in the range -128 to 127, inclusive, and may cache other values outside of this range.

200 is out of the "must cache" range, and thus it falls under "may cache". If it is cached, the value of story won't be eligible for GC when its containing CardBoard instance is. If it isn't cached, story will be unreachable and thus GCed.

To make the question unambiguous (and the proposed answer correct), the code should be amended like this:

Short story = new Short(200);

Update: The 1.6 Javadoc for Short.valueOf() is rather more cryptic than the 1.8 version I quoted, but the same logic applies: there is no way to tell just by looking at the code whether a new or a cached instance of Short will be returned.

Answer 2

Let's break this down line by line:

CardBoard c1 = new CardBoard();

We now have two objects, the CardBoard c1 points at and the Short c1.story. Neither is available for GC as c1 points at the CardBoard and the story variable of the CardBoard points at the Short...

CardBoard c2 = new CardBoard();

Similar to above, we now have four objects, none of which are available for GC.

CardBoard c3 = c1.go(c2);

We invoke the method go on the CardBoard pointed at by c1, passing the value of c2 which is a reference to a CardBoard Object. We null the parameter, but Java is pass by value meaning that the c2 variable itself is unaffected. We then return the nulled parameter. c3 is null, c1 and c2 are unaffected. We still have 4 objects, none of which can be GC'd.

c1 = null;

We null c1. The CardBoard object which c1 previously pointed at now has nothing pointing to it, and it can be GC'd. Because the story variable inside that CardBoard object is the only thing pointing at the Short, and because that CardBoard object is eligible for GC, the Short also becomes eligible for GC. This gives us 4 objects, 2 of which can be GC'd. The objects eligible for GC are the ones formerly referenced by c1 and c1.story.

Answer 3

No object ever existed that c3 points to. The constructor was only called twice, two objects, one each pointed to by c1 and c2. c3 is just a reference, that has never been assigned anything but the null pointer.

The reference c3, that currently points to null, won't go out of scope and be removed from the stack until the closing brace at the end of the main method is crossed.

The object originally assigned to c1 is unreachable because the c1 reference was set to null, but the c2 reference has not been changed, so the object assigned to it is still reachable from this scope via the c2 reference.

Answer 4

c3 is null, so there is clearly no Object there eligible for garbage collection.

Note that only two CardBoard objects are created, the two on these lines:

CardBoard c1 = new CardBoard();
CardBoard c2 = new CardBoard();

and after the reference juggling, only one of them is without references.

Answer 5

If you notice there are only two objects created in the code. c3 is never initialized to an object, it is a null reference. Hence, only one "object" eligible for garbage collection.