*
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes OCP book (K & B) - Exam2 - Num 50 - GC question Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCM Java EE 6 Enterprise Architect Exam Guide this week in the OCMJEA forum!
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "OCP book (K & B) - Exam2 - Num 50 - GC question" Watch "OCP book (K & B) - Exam2 - Num 50 - GC question" New topic
Author

OCP book (K & B) - Exam2 - Num 50 - GC question

Ted North
Ranch Hand

Joined: Jan 02, 2012
Posts: 192
    
    1


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
author
Sheriff

Joined: Sep 28, 2004
Posts: 18765
    
  40

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.



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


Books: Java Threads, 3rd Edition, Jini in a Nutshell, and Java Gems (contributor)
Ted North
Ranch Hand

Joined: Jan 02, 2012
Posts: 192
    
    1

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
author
Sheriff

Joined: Sep 28, 2004
Posts: 18765
    
  40

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?


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
Ranch Hand

Joined: Jan 02, 2012
Posts: 192
    
    1

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



Okay here is what I came up with -


Here is what happens when line 17 is executed (or my interpretation of it ):


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.
ayush raj
Ranch Hand

Joined: Jan 15, 2012
Posts: 60
f3 points to the same location on the heap to which f1.f points and f1.f points to the location of f2 . Thus , all f1.f , f2 and f3 points to the same object . When f2 is made null , the reference variable f3 still holds the address of that created object .
Now , f3.f would still mean f2.f which holds the address of the object referenced by f1 . Thus , the two objects created locally in the go() method still have a reference (f3, f3.f ) and so no objects are eligible for gc . In main() , the two objects created in the go () along with the anonymous object used for calling go () are eligible for gc . Therefore , at line 8 all 3 objects can be garbage collected . Try to figure it out using pen and paper ..
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18765
    
  40

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.


When you do something like this...



It doesn't create an object named "f2" -- it creates a Fiji object on the heap and declares a reference named f2 that points to it. You have to distinguish between references and objects. If you set f2 to null, or a different object, it just means that the previous path from f2 to the old object can't be used. Whether the object is GC will depend if it can be reach via other paths.

Try it again....

Henry
Alex Theedom
Ranch Hand

Joined: Jan 18, 2012
Posts: 48

Hello,

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.

Alex Theedom - Senior Java EE Developer (OCPJP/OCPJWCD)
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18765
    
  40

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.



Hmmm..... let me try to draw this. Although, admittedly, my artwork won't be as good as everyone so far ....

Here the code:



Let's name the objects FIJIA B C etc. in the order that they were instantiated. So Here we go... after this code...



we have ....



after...



we have ....



after...



we have ....



and finally....



we have....



Notice that both objects which were created in the go() method, are still reachable.


Hope this helps,
Henry
Oceana Wickramasinghe
Ranch Hand

Joined: Mar 02, 2011
Posts: 77
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
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18765
    
  40

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
Ted North
Ranch Hand

Joined: Jan 02, 2012
Posts: 192
    
    1

Hi Henry and all,

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
author
Sheriff

Joined: Sep 28, 2004
Posts: 18765
    
  40

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



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
Ted North
Ranch Hand

Joined: Jan 02, 2012
Posts: 192
    
    1

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


Hello Henry,

I think I see what you mean: f3.f is f2.f! This is because they both reference the same object.


Janki Shah
Ranch Hand

Joined: Nov 23, 2011
Posts: 136
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
Ted North
Ranch Hand

Joined: Jan 02, 2012
Posts: 192
    
    1

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


Hi Janki,

My understanding is that at line 8 all of the objects are eligible for garbage collection because the method completes and there is nothing else for the program to do, so GC is called and memory is freed up.

Regards,

TN
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18765
    
  40

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
Ranch Hand

Joined: Nov 23, 2011
Posts: 136
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: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
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18765
    
  40

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
Ranch Hand

Joined: Nov 23, 2011
Posts: 136
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. but 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: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
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18765
    
  40

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
Ranch Hand

Joined: Nov 23, 2011
Posts: 136
Thank you Henry. I think I got the point now.
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
Ranch Hand

Joined: Nov 23, 2011
Posts: 136

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
author
Sheriff

Joined: Sep 28, 2004
Posts: 18765
    
  40

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
Janki Shah
Ranch Hand

Joined: Nov 23, 2011
Posts: 136
Thank you so much Henry.
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
Ted North
Ranch Hand

Joined: Jan 02, 2012
Posts: 192
    
    1

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


I got this answer partly wrong on my second try at OCP Exam 2 and had to revist this thread because I was not sure how f3 was able to reach both objects. But now it makes sense again... I keep forgetting your point about "if f2 and f3 are referring to the same object, then f2.f and f3.f are the same reference..." (Wong, 2012).

Here is an updated drawing I made to try and figure this out in my head:
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: OCP book (K & B) - Exam2 - Num 50 - GC question