Confused about GC in K&B q.12 pg.272

[Rick Reumann]

Consider the following which is modified according to the answer on pg273 question 12:

At what point is only a single object eligible for GC?

public class Eco {
    public static void main(String[] args){
        Eco e1 = new Eco();
        Eco e2 = new Eco();
        Eco e3 = new Eco();
        
        e3.e = e2;
        e1.e = e3;
        e2.e = e1;
        
        e2 = null;
        e3 = null;
        e1 = null;
        
    }
    Eco e;
}

The answer states (after removing the compile error): "'Never in this program' because until the last reference is nulled none of the objects is eligble, and once the last reference is nulled, all three are eligible."

I'm a bit confused of why afer e3 = null, e3 wouldn't be immediately eligble for garbage collection? Once e3 points to null, what still needs the reference to e3 that would make it not eligble?

The only thing I can see is that maybe since e1.e is still pointing to e3 that maybe that keeps it around? But that doesn't seem to make sense since if e3 is poining to null, I wouldn't think e1.e would still need the actual Echo e3 object around?

Thanks for some clarification.

[Henry Wong]

The answer states (after removing the compile error): "'Never in this program' because until the last reference is nulled none of the objects is eligble, and once the last reference is nulled, all three are eligible."

I'm a bit confused of why afer e3 = null, e3 wouldn't be immediately eligble for garbage collection? Once e3 points to null, what still needs the reference to e3 that would make it not eligble?

The only thing I can see is that maybe since e1.e is still pointing to e3 that maybe that keeps it around? But that doesn't seem to make sense since if e3 is poining to null, I wouldn't think e1.e would still need the actual Echo e3 object around?

Thanks for some clarification.

Remember that there is a difference between references and objects. So this instruction say...

e1.e = e3;

The reference "e" in the object pointed to by e1 is assigned to the object pointed to by e3. After this operation, there is now two references pointing to the same object... both e1.e and e3 are now both referencing the same object.

In other words, e1.e is *not* referencing e3, it is referencing the same object that e3 is referencing.

After...

e3 = null;

the e3 reference is now no longer pointing to the object, but the e1.e reference still is.

Henry

[Rick Reumann]

Thanks Henry. As usual "You da man!". Makes perfect sense.

[Jeff Schuler]

Originally posted by Henry Wong:


Remember that there is a difference between references and objects. So this instruction say...

e1.e = e3;

The reference "e" in the object pointed to by e1 is assigned to the object pointed to by e3. After this operation, there is now two references pointing to the same object... both e1.e and e3 are now both referencing the same object.

In other words, e1.e is *not* referencing e3, it is referencing the same object that e3 is referencing.

After...

e3 = null;

the e3 reference is now no longer pointing to the object, but the e1.e reference still is.

Henry

Old post but I had a similar doubt.

Isn't the original poster correct but for another reason?

After 'e3 = null', doesn't the object that e3.e is referring to become eligible? Since e3 is set to null doesn't the compiler realize that e3.e will no longer be able to access the object it refers to?

[Bert Bates]

Hi Rick,

Our experience is that:

1 - GC questions can be some of the trickiest questions on the exam.
2 - It's important to be VERY precise in how you talk about / think about "objects" vs. "references to objects".

When I read your post, it seems to me that you're being a little mushy in how you use the terms "object" and "reference", and that mushiness could get you in trouble

So, for instance, it's not quite precise to refer to the "e3" object. There is no "e3" object! However, it could be that for a while there is an object that is referred to by the "e3 reference".

Next, it's important to be VERY clear that ONLY objects can be garbage collected!!! In other words, it is always incorrect to say or to think that e1, or e2, or e3 will ever or can ever be GCed - they are references, not objects!

Often, when people are discussing these problems they will add line numbers or comments so that they can say: "the object created on line x", this phraseology helps you keep in mind that just because a reference happens to "point" to an object at some point in the code, that doesn't make it, for instance, the "e3" object, since any given object can gain and lose references to it many, many times.

I would suggest that you rephrase your question and try to be as precise in your terminolgy as possible - you might discover that you'll answer you own question! If not, the precise question will lead to a more meaningful discussion.
[ June 23, 2007: Message edited by: Bert Bates ]

[Jeff Schuler]

Does anyone have an explanation to my reply? When an object have instance reference variables and the reference of the object is set to null, does the objects that the instance reference variables refer to become eligible for GC (assuming no other reference variable refer to them)? I'm not sure if that made any sense.

[Srikanth Nakka]

Hi Rick Reumann,

Can you provide full name K&B Book becouse at pg:272 of Head First Java K&B is Blank Page

[Divya Gehlot]

Hi,
I am bit confused with the explanation given above. could any one help me in this matter. As in your explanation there is no such e3 object but its there . Could you please elaborate this

[Divya Gehlot]

Hi,
I am bit confused with the above explanation as you said there is no susch e3 object but its there . could you please elaborate in this matterBert.

[Nik Arora]

Hi Divya,
Eco e3 = new Eco();

Look at the above line. In the above line e3 is a reference to Eco object. So, here Eco is the object and e3 is the reference to Eco object.


Regards
Nik

[Bert Bates]

The short answer is that when you say something like:

Eco e1 = new Eco();

You ar making a new instance (object) of type Eco, and you can refer to that object through the reference variable called e1. The object itself really doesn't have a name - it will usually get you in trouble if you call it, the object, "e1". Reference variables have "names", but objects really don't. As you can see in this example it's quite common to take a reference variable and make it "point" or refer to a different object. The problem with trying to name an object is that whatever reference variable(s) refer to it can change! The common vernacular is to say things like "the object created on line X", or "the object referred to by e1 on line Y".

hth,

Bert

[dhwani mathur]

well!!
please if can anybody answer the question put up by

Jeff Schuler

Does anyone have an explanation to my reply? When an object have instance reference variables and the reference of the object is set to null, does the objects that the instance reference variables refer to become eligible for GC (assuming no other reference variable refer to them)? I'm not sure if that made any sense



i want to know if object is elligible for GC?

Please if anyone could explain this will be kinda of you. :roll:

[Nik Arora]

Does anyone have an explanation to my reply? When an object have instance reference variables and the reference of the object is set to null, does the objects that the instance reference variables refer to become eligible for GC (assuming no other reference variable refer to them)? I'm not sure if that made any sense



i want to know if object is elligible for GC?

Please if anyone could explain this will be kinda of you.

Hi Dhwani,
Yes the object will be eligible for garbage collection.

Regards
Nik

[dhwani mathur]

Hey Nik!!
Thanks once again!!!