Ted North wrote:
This image I drew that shows how the objects relate to each and how many there are before they are nullified at line 17.
I drew this image that shows how I am picturing the objects being nullified.
************************
Here is the code from the Exam: (Exam 2 question 50)
Which are true? (Choose all that apply.)
A. At line 8, one object is eligible for garbage collection.
B. At line 8, two objects are eligible for garbage collection.
C. At line 8, three objects are eligible for garbage collection.
D. At line 18, 0 objects are eligible for garbage collection.
E. At line 18, two objects are eligible for garbage collection.
F. At line 18, three objects are eligible for garbage collection.
Can someone please try and explain how the answer is C and D. It looks like about six objects are created until the code reaches line 15. After line 15 it looks like f3 and its f3.f member is left and I see that the anonymous Fiji is also left off the garbage heap.
Henry Wong wrote:
First, can you tell us where the "six objects are created"? From tracing the code, there are only three places that the "new" operator is called -- and there aren't any loops and such.
Henry
Ted North wrote:
Henry Wong wrote:
First, can you tell us where the "six objects are created"? From tracing the code, there are only three places that the "new" operator is called -- and there aren't any loops and such.
Henry
Oh, excellent point about the new keyword. I do see that in only three places in the code. I guess there are only 3 objects then and not six. There must be 3 objects and three references to these objects or object references that point to object references of the objects. Is this correct?
Henry Wong wrote:
Yes, basically, when drawing stuff out, you need to distinguish between objects and references. For garbage collection questions, keep track of all references to those objects -- and only when all the references are broken (and object is no longer reachable) from the root, can you consider the object eligible for GC.
Try it again. I would be interested to see the pictures.
Henry
Ted North wrote:
I know I am missing something because the answer in the book says, "C and D are correct. A total of three Fiji objects are created. At line 18, the anonymous (main()’s), Fiji can still be accessed via "this", and the other two Fiji objects can be accessed via f3 (f3 and f3.f). At line 8, none of the three Fiji objects are accessible. A, B, E, and F are incorrect based on the above".
I am not sure how f3 and f3.f can be accessed if f2 is nullified? Can you explain Henry or someone else reading this please?
Thank you for your help Henry I appreciate the interest in my drawings.
Alex Theedom. Author of: Java EE Video Courses (JAX-RS, Bean Validation, Websocket, JSON-P and much more), Java EE 8: Only What's New
and Professional Java EE Design Patterns. Blogger at readlearncode.com. Twitter @alextheedom
Alex Theedom wrote:
I am a little confused with regard to the reference f3.f at line 18. To which object is the reference f3.f set? I cannot see this set in the code.
This is how I see it:
Two objects are reachable and one is eligible for gc.
I am sure I am missing something obvious. Thank you in advance for your help.
Alex.
Oceana Wickramasinghe wrote:I understand how all three objects get wiped out, but why it that 0 objects are garbage collected on line 18, i mean there are two objects within the go method.
Is it because
A. All the objects have already been garbage collected
B. Because method isnt done executing
Ted North wrote:
Thanks for your input on this question. I have a much better idea as to what is going on now.
A colleague of mine made this drawing to help explain. Maybe it would help someone else reading this.
---
tl:dr - F3 reference is maintained after null is called on other references. The F1.f maintains reference to 2nd object and F2.f maintains reference to 1st object, while the anonymous class that started off the go is also still "alive" like the portal robot.
When go method ends all the objects left are eligible for garbage collection because there is nothing else going on, hence C and D are the correct answers.
This maybe a little off but for the most part correct. For instance f3.f is never explicitly assigned in the program and the answers say that this object is still alive at line 18 but it is not show in my friend's and I's diagram.
Regards,
TN
Henry Wong wrote:
The phrase "f3.f is never explicitly assigned" is incorrect -- if you are talking about the reference. Remember that with "f3.f", the reference is the "f" reference on the object being referred to by the "f3" reference, and the object only has one "f" reference, regardless on how you reach it. So, if "f2" and "f3" are referring to the same object, then "f2.f" and "f3.f" are the same reference. The "f3.f" reference is being set, even though the "f3" reference is not used to get to the object.
Henry
Henry Wong wrote:
Oceana Wickramasinghe wrote:I understand how all three objects get wiped out, but why it that 0 objects are garbage collected on line 18, i mean there are two objects within the go method.
Is it because
A. All the objects have already been garbage collected
B. Because method isnt done executing
Sorry, I was still working on the drawings when you posted this -- so take a look at my previous post.
But to answer your question... For (A), no, the objects are still reachable. For (B), no, same reason.
Henry
Janki Shah wrote:I understood the point that at line 18, 0 objects are eligible for GC since two objects are created in the go method are still reachable. But what I don't understand is how come at line 8 three objects are eligible for GC? Can you please explain little more? Thank you.
Henry Wong wrote:
Oceana Wickramasinghe wrote:I understand how all three objects get wiped out, but why it that 0 objects are garbage collected on line 18, i mean there are two objects within the go method.
Is it because
A. All the objects have already been garbage collected
B. Because method isnt done executing
Sorry, I was still working on the drawings when you posted this -- so take a look at my previous post.
But to answer your question... For (A), no, the objects are still reachable. For (B), no, same reason.
Henry
Janki Shah wrote:I understood the point that at line 18, 0 objects are eligible for GC since two objects are created in the go method are still reachable. But what I don't understand is how come at line 8 three objects are eligible for GC? Can you please explain little more? Thank you.
Henry Wong wrote:
Oceana Wickramasinghe wrote:I understand how all three objects get wiped out, but why it that 0 objects are garbage collected on line 18, i mean there are two objects within the go method.
Is it because
A. All the objects have already been garbage collected
B. Because method isnt done executing
Sorry, I was still working on the drawings when you posted this -- so take a look at my previous post.
But to answer your question... For (A), no, the objects are still reachable. For (B), no, same reason.
Henry
Henry Wong wrote:
Janki Shah wrote:I understood the point that at line 18, 0 objects are eligible for GC since two objects are created in the go method are still reachable. But what I don't understand is how come at line 8 three objects are eligible for GC? Can you please explain little more? Thank you.
Henry Wong wrote:
Oceana Wickramasinghe wrote:I understand how all three objects get wiped out, but why it that 0 objects are garbage collected on line 18, i mean there are two objects within the go method.
Is it because
A. All the objects have already been garbage collected
B. Because method isnt done executing
Sorry, I was still working on the drawings when you posted this -- so take a look at my previous post.
But to answer your question... For (A), no, the objects are still reachable. For (B), no, same reason.
Henry
The reason is simple... at line 8, the objects are no longer reachable. Objects are eligible for GC when they are not reachable from a root.
Henry
Janki Shah wrote:Thank you Ted and Henry for your answers.
At line 8 objects are not reachable. Is it because the anonymous object create at line 7 is no longer reachable (no reference to it) and accordingly the two objects which are created in go() method are also not reachable. Please correct me if I am wrong. I am little confuse in understanding that, how the objects are not reachable at line 8?
Henry Wong wrote:
Janki Shah wrote:Thank you Ted and Henry for your answers.
At line 8 objects are not reachable. Is it because the anonymous object create at line 7 is no longer reachable (no reference to it) and accordingly the two objects which are created in go() method are also not reachable. Please correct me if I am wrong. I am little confuse in understanding that, how the objects are not reachable at line 8?
Let's reverse the question -- how do you think that those objects would be reachable?
Henry
Janki Shah wrote:Because in method go() f3 reference variable is still pointing to the object created by f2 and f3.f (f2 == f3)is pointing to the object created by f1. So both object are reachable.
Janki Shah wrote:I am not sure about the object created at line 7 that, Is there any reference to it or not? But I think that there is no reference to that object created at line 7 and because of that we can not reach the objects created by calling go() method on it.
Henry Wong wrote:
Janki Shah wrote:Because in method go() f3 reference variable is still pointing to the object created by f2 and f3.f (f2 == f3)is pointing to the object created by f1. So both object are reachable.
Incorrect. At line 8, the go() method has completed, so "f3", which is a local variable of the method, is out of scope.
Janki Shah wrote:I am not sure about the object created at line 7 that, Is there any reference to it or not? But I think that there is no reference to that object created at line 7 and because of that we can not reach the objects created by calling go() method on it.
This is correct. There is no references to the object created at line 7, from line 8.... however, the conclusion draw, meaning how this object being not reachable implies the other two objects being not reachable is incorrect.
Henry
Janki Shah wrote:
Sorry one last question about this. So, if we change line 7 as shown above how many objects will be able to GCed? two?
Henry Wong wrote:
Janki Shah wrote:
Sorry one last question about this. So, if we change line 7 as shown above how many objects will be able to GCed? two?
Correct. If you make the change (now on line 5 and line 6) as shown, the object created on line 5 is still reachable (and hence, not eligible for GC) on line 7.
Henry
Henry Wong wrote:
The phrase "f3.f is never explicitly assigned" is incorrect -- if you are talking about the reference. Remember that with "f3.f", the reference is the "f" reference on the object being referred to by the "f3" reference, and the object only has one "f" reference, regardless on how you reach it. So, if "f2" and "f3" are referring to the same object, then "f2.f" and "f3.f" are the same reference. The "f3.f" reference is being set, even though the "f3" reference is not used to get to the object.
Henry
Spot false dilemmas now, ask me how!
(If you're not on the edge, you're taking up too much room.)
Ew. You guys are ugly with a capital UG. Here, maybe this tiny ad can help:
Gift giving made easy with the permaculture playing cards
https://coderanch.com/t/777758/Gift-giving-easy-permaculture-playing
|