• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Bear Bibeault
  • Jeanne Boyarsky
  • Tim Cooke
Sheriffs:
  • Knute Snortum
  • Junilu Lacar
  • Devaka Cooray
Saloon Keepers:
  • Ganesh Patekar
  • Tim Moores
  • Carey Brown
  • Stephan van Hulst
  • salvin francis
Bartenders:
  • Ron McLeod
  • Frits Walraven
  • Pete Letkeman

Self Test Answers Chapter 3 Question 11  RSS feed

 
Ranch Hand
Posts: 36
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
According to the book the correct answer for this question is that one object will be elegible for garbage collector.
I'm wondering if the correct answer would be the letter C.

Looking at the picture above the a1 (Alpha) and a1's b2 reference variable would not be elegible for garbage collector?

follow the code:




thanks for the help!!!


[edit] code attached
 
Sheriff
Posts: 9613
37
Android Google Web Toolkit Hibernate IntelliJ IDE Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It would be nice if you post the code too so that we know the diagram is correct or not...
 
Bartender
Posts: 3185
34
Google App Engine Java Ruby
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
One object- The object create on line 11 initially referred by a1.

Why would the object referred by a1.b2 be eligible for GC, when the same reference can be accessed by- Alpha.b1
 
Jose Coqueiro
Ranch Hand
Posts: 36
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Look at the diagram, In fact the a1.b2 object can't be accessed by a2.b1 because a1.b2 object is a instance variable and once a1 is set to null the a1.b2 couldn't be reached anymore.
 
Mohamed Sanaulla
Bartender
Posts: 3185
34
Google App Engine Java Ruby
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Jose Coqueiro wrote:Look at the diagram, In fact the a1.b2 object can't be accessed by a2.b1 because a1.b2 object is a instance variable and once a1 is set to null the a1.b2 couldn't be reached anymore.



The b1 is static and hence shared by different instances. Here a1.b2 is not an object, but its just a reference (think like pointer) to the instance. Same is the case with Alpha.b1. So though a1 is set to null, the object referred by a1.b2 can still be reached by using the reference- a2.b1 or Alpha.b1.
 
Jose Coqueiro
Ranch Hand
Posts: 36
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
OK. But the self test answer question 1 suggest otherwise:



Accordint to the book the correct answer for this question is that two objects are elegible for GC, c1 ans its associated Short wrapper object.

Based on this questions I was thinking the question 11 could be also two objects, since Alpha objects has an associated non-static Beta object.
 
Mohamed Sanaulla
Bartender
Posts: 3185
34
Google App Engine Java Ruby
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In the first example the references within the class Alpha are pointing to the same instances created in your main program. When you assign one reference variable to another- the references are copied but the objects remain the same and is not copied to create a new object.

But in the later example- the Short reference variable is referring to a separate instance.
 
Jose Coqueiro
Ranch Hand
Posts: 36
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Each Alpha object has its an associated Beta object called b2, and their reffers to a diferent instances too, it's not the same.

When a1 is set to null, a1 is elegible for gc, and once it has an associated Beta object (b2) it's also elegible for gc.

Doesn't matter whether b1 object created at line 10 is still being referred by a2.b1, the a1.b2 can't reach any object because a1 was set to null, thus I think it should be elegible for gc.
 
Mohamed Sanaulla
Bartender
Posts: 3185
34
Google App Engine Java Ruby
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Jose Coqueiro wrote:Each Alpha object has its an associated Beta object called b2, and their reffers to a diferent instances too, it's not the same.



Can you please explain how?

Jose Coqueiro wrote:
... and once it has an associated Beta object (b2) it's also elegible for gc.


The b2 reference within the class Alpha is not an object.

Jose Coqueiro wrote:
Doesn't matter whether b1 object created at line 10 is still being referred by a2.b1, the a1.b2 can't reach any object because a1 was set to null, thus I think it should be elegible for gc.



Do you know when the objects are eligible for Garbage Collection?

And a question for you: How many objects are created in the first code you have posted? And how many references are there in the same code?
 
Mohamed Sanaulla
Bartender
Posts: 3185
34
Google App Engine Java Ruby
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
And also please note that b1 and b2 within the class Alpha are not the same as the b1 and b2 in the main method. So if b1 and b2 in main point to some objects, this doesnt mean b1 and b2 in Alpha class will also point to the same objects.
 
Greenhorn
Posts: 12
Eclipse IDE Google Web Toolkit Oracle
  • Likes 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Question 1 is a bit different because in creating a CardBoard a Short is initialized by setting it to 200 (object created). For question 11, the Beta b2 is not initialized (defaults to null/no new object is created). The static beta b1 is also default null (no new object created). Creating an Alpha creates only one Object that has one null reference that is shared among all the Alphas and its own null reference b2.

This is how I see the problem:

At line 11, 4 objects have been created: b1 pointing to Beta, b2 pointing to another Beta, a1 pointing to an Alpha (which has no objects just null variables), and a2 pointing to another Alpha (which has no objects just null variables).

The null a1.b1 points to the existing Beta b1 points to. Since this is a static variable it also sets a2.b1 to the existing Beta b1 points to.
The null a1.b2 point to the existing Beta b1 points to.
The null a2.b2 points to the existing Beta b2 points to.

Reference variables a1, b1, b2 are set to null.

The only external reference left is a2 (One object). Which has two references. a2.b1 still points to the object b1 used to point to (saved object). a2.b2 still points to the object b2 used to point to (saved object). The only object that is GC is the object a1 used to point to (no external references). Of the original 4 objects, only 1 is GC.
 
Mohamed Sanaulla
Bartender
Posts: 3185
34
Google App Engine Java Ruby
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have attached a visual on the final state of the objects and references

Note: The b1 and b2 beside a1 and a2 stand for the reference variables within class Alpha. The first two b1 and b2 are the references of type Beta created in main method.
GC_Graphs.JPG
[Thumbnail for GC_Graphs.JPG]
GC Depiction
 
Jose Coqueiro
Ranch Hand
Posts: 36
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Mohamed Sanaulla wrote:And also please note that b1 and b2 within the class Alpha are not the same as the b1 and b2 in the main method. So if b1 and b2 in main point to some objects, this doesnt mean b1 and b2 in Alpha class will also point to the same objects.


Of course!!!

Jose Coqueiro wrote:Each Alpha object has its an associated Beta object called b2, and their reffers to a diferent instances too, it's not the same.

Mohamed Sanaulla wrote:Can you please explain how?





Jose Coqueiro wrote:... and once it has an associated Beta object (b2) it's also elegible for gc.

Mohamed Sanaulla wrote:The b2 reference within the class Alpha is not an object.



in this code are just pointers, you're right...


I guess I understand your viewpoint, the a1.b2 was not created, in others words was not created with the keyword new, it is just pointing to a previously existing object!

thanks for the help!


 
Ranch Hand
Posts: 394
Eclipse IDE Java Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Eric Kizaki wrote:Question 1 is a bit different because in creating a CardBoard a Short is initialized by setting it to 200 (object created). For question 11, the Beta b2 is not initialized (defaults to null/no new object is created). The static beta b1 is also default null (no new object created). Creating an Alpha creates only one Object that has one null reference that is shared among all the Alphas and its own null reference b2.

This is how I see the problem:

At line 11, 4 objects have been created: b1 pointing to Beta, b2 pointing to another Beta, a1 pointing to an Alpha (which has no objects just null variables), and a2 pointing to another Alpha (which has no objects just null variables).

The null a1.b1 points to the existing Beta b1 points to. Since this is a static variable it also sets a2.b1 to the existing Beta b1 points to.
The null a1.b2 point to the existing Beta b1 points to.
The null a2.b2 points to the existing Beta b2 points to.

Reference variables a1, b1, b2 are set to null.

The only external reference left is a2 (One object). Which has two references. a2.b1 still points to the object b1 used to point to (saved object). a2.b2 still points to the object b2 used to point to (saved object). The only object that is GC is the object a1 used to point to (no external references). Of the original 4 objects, only 1 is GC.



Hi Eric, your explanation is very good!, I decided to add a diagram to visualize all that you have explained, and it made a lot of sense:

The Key Point Here Is:



Once a static variable is given a value, that value is the same for all instances of the class.



Beta_Alpha.png
[Thumbnail for Beta_Alpha.png]
Alpha_Beta Diagram.
 
Ranch Hand
Posts: 430
Android Debian VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Eric Kizaki wrote:Question 1 is a bit different because in creating a CardBoard a Short is initialized by setting it to 200 (object created). For question 11, the Beta b2 is not initialized (defaults to null/no new object is created). The static beta b1 is also default null (no new object created). Creating an Alpha creates only one Object that has one null reference that is shared among all the Alphas and its own null reference b2.

This is how I see the problem:

At line 11, 4 objects have been created: b1 pointing to Beta, b2 pointing to another Beta, a1 pointing to an Alpha (which has no objects just null variables), and a2 pointing to another Alpha (which has no objects just null variables).

The null a1.b1 points to the existing Beta b1 points to. Since this is a static variable it also sets a2.b1 to the existing Beta b1 points to.
The null a1.b2 point to the existing Beta b1 points to.
The null a2.b2 points to the existing Beta b2 points to.

Reference variables a1, b1, b2 are set to null.

The only external reference left is a2 (One object). Which has two references. a2.b1 still points to the object b1 used to point to (saved object). a2.b2 still points to the object b2 used to point to (saved object). The only object that is GC is the object a1 used to point to (no external references). Of the original 4 objects, only 1 is GC.



Brilliant explanation. I spent ages trying to understand this question but you've nailed it!

I was not sure about this bit in your explanation:


I didnt know that a static variable will be initialised implicitly even if the code does not initialise it so i wrote a simple code bit to test it.



The output to the above is

false
false



So it does look like a2.a was initialised implicitly even though the code did not explicitly initialise it.



 
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

O. Ziggy wrote:

Eric Kizaki wrote:Question 1 is a bit different because in creating a CardBoard a Short is initialized by setting it to 200 (object created). For question 11, the Beta b2 is not initialized (defaults to null/no new object is created). The static beta b1 is also default null (no new object created). Creating an Alpha creates only one Object that has one null reference that is shared among all the Alphas and its own null reference b2.

This is how I see the problem:

At line 11, 4 objects have been created: b1 pointing to Beta, b2 pointing to another Beta, a1 pointing to an Alpha (which has no objects just null variables), and a2 pointing to another Alpha (which has no objects just null variables).

The null a1.b1 points to the existing Beta b1 points to. Since this is a static variable it also sets a2.b1 to the existing Beta b1 points to.
The null a1.b2 point to the existing Beta b1 points to.
The null a2.b2 points to the existing Beta b2 points to.

Reference variables a1, b1, b2 are set to null.

The only external reference left is a2 (One object). Which has two references. a2.b1 still points to the object b1 used to point to (saved object). a2.b2 still points to the object b2 used to point to (saved object). The only object that is GC is the object a1 used to point to (no external references). Of the original 4 objects, only 1 is GC.



Brilliant explanation. I spent ages trying to understand this question but you've nailed it!

I was not sure about this bit in your explanation:


I didnt know that a static variable will be initialised implicitly even if the code does not initialise it so i wrote a simple code bit to test it.



The output to the above is

false
false



So it does look like a2.a was initialised implicitly even though the code did not explicitly initialise it.





Instance and class (static) variables are automatically initialized to standard default values. The default value for objects is null, so if you initialized explicitly your Beta static variable to null or not, you will get that both Beta references from a1 and a2, reference to null.
Commenting the line a1.a = new Beta(); will produce the output true true


 
Greenhorn
Posts: 28
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm really glad to have found all this help on Chapter 3's problem 11 because I don't think that I would have figured it out otherwise. Thank you everyone for all of your input here! The key points that I had to first understand were:

1) There are FOUR objects created on the heap (two Betas and two Alphas).
2) Line 12 sets a1.b2 = b1. Because the Beta b1 is static, this means that now ALL Alpha's b1s are set to equal b1 (i.e., now a2.b1 = b1).
3) It is a trick to have the static Beta in the Alpha class named "b1", and the Beta reference variable in the main method also named "b1". These two b1s aren't the same thing. To see what was really going on, on lines 10,12, and 14, I changed "b1" to "abc123". The program worked exactly the same.
4) To represent what happens on lines 10 and 11, I drew a picture of the four objects on the heap, two Betas and two Alphas and drew the following arrows:
a) "b1" ----> "Beta Object #1"
b) "b2" ----> "Beta Object #2"
c) "a1" ----> "Alpha Object #1"
d) "a2" ----> "Alpha Object #2"
5) To represent what happens on line 12, I drew the following arrows:
a) "a1.b1" ----> "Beta Object #1"
b) "a2.b1" ----> "Beta Object #1" (This line gets drawn because the Beta b1 is static, so after line 10, ALL Alpha's b1s are set to equal b1)
6) To represent what happens on line 13, I drew the following arrow:
a) "a1.b2" ----> "Beta Object #1" (There are now THREE arrows pointing at "Beta Object #1")
7) To represent what happens on line 14, I drew the following arrow:
a) "a2.b2" ----> "Beta Object #2"
8) To represent what happens on line 15, I drew the following "X"s:
a) I "x"ed out the arrow pointing from a1 to "Alpha Object #1".
*This makes the arrow from "a1.b1" to "Beta Object #1" and the arrow from "a1.b2" to "Beta Object #1" be x'ed out too!
b) I "x"ed out the arrow pointing from b1 to "Beta Object #1"
c) I "x"ed out the arrow pointing from b2 to "Beta Object #2"
9) Any object that didn't have an arrow pointed at it is eligible for garbage collection. So this means that ONLY "Alpha Object #1" is eligible for GC.

This is a picture of what I mean:




 
Ranch Hand
Posts: 228
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Katherine Reut wrote:
    a) I "x"ed out the arrow pointing from a1 to "Alpha Object #1".
            *This makes the arrow from "a1.b1" to "Beta Object #1" and the arrow from "a1.b2" to "Beta Object #1" be x'ed out too!



Hi Ranchers,

Could you kindly refresh my memory on the specific rules for the above asterisk?  Or, perhaps, provide more insight?  By the way, I think this is one of the better diagrams that I've seen since it "keeps" both sets of b1&b2 within heap objects referenced by a1 and a2.  If you have a better diagram, by all means, please feel free to share it.

Answer:


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.



My memory somehow wants to see a1, a1.b1, and a1.b2 as three separate (independent) references, similar to how the above answer seemingly (to me) treats a2, a2.b1, and a2.b2 as separate references?

Thanks in advance!
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!