This would be the instance initially assigned to a1.
The instance assigned to b1 still has a static reference to it (a1.b1 = b1), the instance assigned to b2 is still referenced by the instance in a2, and the instance in a2 is referenced by, well... a2.
Technically though, in the code as you have posted it, line 16 is not part of any method so the amount of objects (eligible or not) is undefined.
At the very least, after the main method has run, 3 of the objects are eligible for garbage collection (referenced by a1, a2 and b2) because they only have local references to them in the main method. b1 is referenced statically.
The mind is a strange and wonderful thing. I'm not sure that it will ever be able to figure itself out, everything else, maybe. From the atom to the universe, everything, except itself.
Joined: Nov 14, 2010
Good catch, I did put an extra blank line in the code at line 16.
The response from the books is as follows:
"It should be clear that there is still a reference to the object referred to by a2, and that there is still a reference to the object referred to by a2.b2. What might be less clear is that you can still access the other Beta object through the static variable a2.b1--because it's static."
I guess what I'm not getting is why the b1 object in Tester is not eligible for garbage collection. Since a1 is set to null and b1 is set to null, then what is still referencing b1?
Jan please Use Code Tags when you post a source code. That way your code looks formatted. Unformatted code is hard to read. You can add code tags by wrapping your code in [code] [/code] tags. You can edit your message using button and then add code tags to it...
while doing GC questions, please try to draw diagrams when ever a new object is created. i mark them as circles.
add arrows to them when ever references are assigned. removes arrows when they are assigned null. this gives a clear picture of how many objects at the end are available with zero references.
Jan tenpas wrote:When line 16 is reached, how many objects will be eligible for garbage collection?
hello jan, i had the same question some monthes ago. the rule you must apply here is that an object is only eligible by the gc when it has no references on it. perhaps to understand this gc problem it helps you to differentiate between stack and heap. the stack is a piece of memory where all references to objects are stored. the heap is a piece of memory where the objects live.
in the given code four objects are instantiated, lets call them A1, A2, B1 and B2. the object B1 is referenced by b1, A1.b1 and A1.b2. so B1 will not be eligible by nulling b1, because the other references are still there. B2 has two references on it, on by b2 and the other by A2.b2. so even by nulling the b2 there is still one reference on it, so this object will not be eligible. the next object is A1 that has only one reference from a1. so by nulling a1 this object will be eligible by the gc. the last object is A2 that has also only one reference from a2. but this reference is not set to null so also this object is not eligible for the gc. so looking once again at the four objects we can see that only 1 object is eligible. so the answer given in the book is right if you need further help, let me know.
Harry, sorry for nitpicking (again), but objects may be eligible for collection even if they have references to them. What you mean is *reachable references*, which is an important difference. If two objects reference eachother, but nothing else does, they may still be garbage collected because they are not reachable.
Joined: Apr 08, 2010
Stephan van Hulst wrote:Harry, sorry for nitpicking (again), but objects may be eligible for collection even if they have references to them. What you mean is *reachable references*, which is an important difference. If two objects reference eachother, but nothing else does, they may still be garbage collected because they are not reachable.
no problem. this page explain the types of reference objects.