aspose file tools*
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes Garbage Collection Madness - SCJP Chapter 3 Self_Exam Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "Garbage Collection Madness - SCJP Chapter 3 Self_Exam" Watch "Garbage Collection Madness - SCJP Chapter 3 Self_Exam" New topic
Author

Garbage Collection Madness - SCJP Chapter 3 Self_Exam

Ted North
Ranch Hand

Joined: Jan 02, 2012
Posts: 193
    
    1

Hello java-nauts,

Even though java virtual machine seems to be fraught with vulnerabilities that attackers have been able to take advantage of, I have decided to keep on studying the SE API for the certification.

So, my question is, given this code (question number 1 in Chapter 3 of the exam) why is c3 not eligible for garbage-collection?



I think c3 should be null because whatever is passed to the go method in the CardBoard class is set to null then returned.

Regards,

TN

Praveen Kumar M K
Ranch Hand

Joined: Jul 03, 2011
Posts: 256
At line 10, there is no new Cardboard object created...c3 isn't and wasn't pointing to any Cardboard object. So maybe the answer means that there is nothing to be garbage collected.
Ted North
Ranch Hand

Joined: Jan 02, 2012
Posts: 193
    
    1

Praveen Kumar M K wrote:At line 10, there is no new Cardboard object created...c3 isn't and wasn't pointing to any Cardboard object. So maybe the answer means that there is nothing to be garbage collected.


Thank you for the reply Kumar. Doesnt the method invocation return null to c3?

The answer says that there are 2 objects eligible for GC. From the book, "Only one CardBoard object (c1) is eligible, but it has an associated Short wrapper object that is also eligible" (K & B, p. 277).

Respectfully,

TN
Tim McGuire
Ranch Hand

Joined: Apr 30, 2003
Posts: 820

Ted North wrote:
Even though java virtual machine seems to be fraught with vulnerabilities that attackers have been able to take advantage of, I have decided to keep on studying the SE API for the certification.


I'm glad nobody uses this criteria in judging whether to use a language, because then we would have no software at all.
Yalvin Duha
Ranch Hand

Joined: Apr 07, 2012
Posts: 40

Ted North wrote:
Thank you for the reply Kumar. Doesnt the method invocation return null to c3?

"c3" is just a reference variable of type CardBoard. Once it is declared (on line 10), it is immediately assigned a "null" value to (when CardBoard.go() is returned), we can conclude that "c3" was not pointing to any object to begin with. No object referenced by "c3" means no GC is necessary. Pretty straightforward.

The second object that is eligible for GC is an object that c1's instance reference variable "story" points to which is a Short object (autoboxing of "int" 200 to Short). Since "c1" is eligible to be removed from the heap by the GC, an object that its member variable points to (and has no other live reference to it after "c1" is nullified), it too becomes eligible for GC. So there are two objects to be collected.

c1 --> c1object (of type CardBoard)
c1.story --> storyobject (of type Short)
Ted North
Ranch Hand

Joined: Jan 02, 2012
Posts: 193
    
    1

Yalvin Duha wrote:
Ted North wrote:
Thank you for the reply Kumar. Doesnt the method invocation return null to c3?

"c3" is just a reference variable of type CardBoard. Once it is declared (on line 10), it is immediately assigned a "null" value to (when CardBoard.go() is returned), we can conclude that "c3" was not pointing to any object to begin with. No object referenced by "c3" means no GC is necessary. Pretty straightforward.

The second object that is eligible for GC is an object that c1's instance reference variable "story" points to which is a Short object (autoboxing of "int" 200 to Short). Since "c1" is eligible to be removed from the heap by the GC, an object that its member variable points to (and has no other live reference to it after "c1" is nullified), it too becomes eligible for GC. So there are two objects to be collected.

c1 --> c1object (of type CardBoard)
c1.story --> storyobject (of type Short)


Thank you for the detailed explanation. The first paragraph about how since c3 was never assigned an object it is not eligible for garabage collection was particularly helpful for me.
Matthew Brown
Bartender

Joined: Apr 06, 2010
Posts: 4422
    
    8

One thing to remember: references are not garbage collected. Objects are. So with questions like this you need to count the number of objects that are created, and work out which ones are no longer referred to by anything. The number of references that are null is a red herring.
Praveen Kumar M K
Ranch Hand

Joined: Jul 03, 2011
Posts: 256
Have a question here...If you have objects of a class like this,



For each garbage collected OuterShell object, do you count twice? One for OuterShell itself and one for innerShell...
Ted North
Ranch Hand

Joined: Jan 02, 2012
Posts: 193
    
    1

Praveen Kumar M K wrote:Have a question here...If you have objects of a class like this,



For each garbage collected OuterShell object, do you count twice? One for OuterShell itself and one for innerShell...



Hello Praveen,

From my understanding of garbage-collection (gc) you are correct. When the OuterShell object is garbage collected its Short wrapper object datatype instance will also be gc'd

Please correct me if I am wrong someone out there...

Regards,

Ted North
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18896
    
  40

Ted North wrote:
Praveen Kumar M K wrote:Have a question here...If you have objects of a class like this,



For each garbage collected OuterShell object, do you count twice? One for OuterShell itself and one for innerShell...



Hello Praveen,

From my understanding of garbage-collection (gc) you are correct. When the OuterShell object is garbage collected its Short wrapper object datatype instance will also be gc'd

Please correct me if I am wrong someone out there...

Regards,

Ted North



Unfortunately, this is a bad example. In this case, the Short object is being autoboxed -- and the Short class will cached Short objects from -128 to 127, for the boxing operation. So, no, the Short object will not be GC'ed, as it is still reachable by the cache.

Henry


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

Joined: Jan 02, 2012
Posts: 193
    
    1

Hi Henry,

Why won't the Short wrapper object be garbage collected (gc'd)? From the answer given in the SCJP book for the Chapter 3 Self_Exam question 1 it would seem that this is how garbage collection works with object instance variables.

Regards,

TN
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18896
    
  40

Ted North wrote:Hi Henry,

Why won't the Short wrapper object be garbage collected (gc'd)? From the answer given in the SCJP book for the Chapter 3 Self_Exam question 1 it would seem that this is how garbage collection works with object instance variables.

Regards,

TN


In the example from the book, the Short object is GC'ed -- as the value 200 is outside the cache range. It is the other example, the example that I quoted, that I said was the bad example.

Henry
Ted North
Ranch Hand

Joined: Jan 02, 2012
Posts: 193
    
    1

Henry Wong wrote:
Ted North wrote:Hi Henry,

Why won't the Short wrapper object be garbage collected (gc'd)? From the answer given in the SCJP book for the Chapter 3 Self_Exam question 1 it would seem that this is how garbage collection works with object instance variables.

Regards,

TN


In the example from the book, the Short object is GC'ed -- as the value 200 is outside the cache range. It is the other example, the example that I quoted, that I said was the bad example.

Henry


Hi Henry,

Wow, thank-you for pointing that the range in the example is out of scope for a Short. So if the integer value is out of range for a Short wrapper object then it is gc'd otherwise it is simply cached even if the object it belongs to is garbage collected?

Regards,

TN
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18896
    
  40

Ted North wrote:
Wow, thank-you for pointing that the range in the example is out of scope for a Short. So if the integer value is out of range for a Short wrapper object then it is gc'd otherwise it is simply cached even if the object it belongs to is garbage collected?



First, this topic is very likely *not* covered by the SCJP -- so feel free to ignore.....










Still here? .... okay .... The Java Language Specification mandates that certain values be cached during the autoboxing process. This is mentioned in section 5.1.7 of the JLS....

http://docs.oracle.com/javase/specs/jls/se7/html/jls-5.html#jls-5.1.7

The exact quote is ....

If the value p being boxed is true, false, a byte, or a char in the range \u0000 to \u007f, or an int or short number between -128 and 127 (inclusive), then let r1 and r2 be the results of any two boxing conversions of p. It is always the case that r1 == r2.

Ideally, boxing a given primitive value p, would always yield an identical reference. In practice, this may not be feasible using existing implementation techniques. The rules above are a pragmatic compromise. The final clause above requires that certain common values always be boxed into indistinguishable objects. The implementation may cache these, lazily or eagerly. For other values, this formulation disallows any assumptions about the identity of the boxed values on the programmer's part. This would allow (but not require) sharing of some or all of these references.

This ensures that in most common cases, the behavior will be the desired one, without imposing an undue performance penalty, especially on small devices. Less memory-limited implementations might, for example, cache all char and short values, as well as int and long values in the range of -32K to +32K.


Also, there is no mandate that values outside of the mandatory caching range be not cached. So, implementations are free to cache whatever range they like, provided that they cover the minimum range required. For the current Oracle implementation, Long objects are also cached, even though the JLS doesn't require it. Also, the implementation has configuration options to allow the JVM to be started to cache a larger range for the Integer class.

Henry


Ted North
Ranch Hand

Joined: Jan 02, 2012
Posts: 193
    
    1



Hi Henry,

That is amazingly complicated! I am glad I do not need to know this for the SCJP. This is news to me that some of these wrapper objects are cached in memory or in the virtual machine.

Do you have experience programming java virtual machines that cached wrapper objects like this?

Respectfully,

TN
Praveen Kumar M K
Ranch Hand

Joined: Jul 03, 2011
Posts: 256
Henry, thanks for clarifying that!

Regards,
Praveen.
Bert Bates
author
Sheriff

Joined: Oct 14, 2002
Posts: 8829
    
    5
I'm not so sure that any part of this discussion is clearly "out of bounds" for the real exam. To me this discussion is on the edge of "in" vs. "out" and I'd tend towards studying 110% of what you think might be on the exam.

hth,

Bert


Spot false dilemmas now, ask me how!
(If you're not on the edge, you're taking up too much room.)
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Garbage Collection Madness - SCJP Chapter 3 Self_Exam