• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

garbage collection question k&b practice exam 3

 
Ash Gill
Ranch Hand
Posts: 71
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hi friends,

i found this question doubtful, can anyone please explain:

find no. of objects eligible for garbage collection when line 8 is reached.


the answer is 4, explaination says, the annonymous Banker object, Account object and two Long objects created in go(). aren't there 3 Long objects being created in go(), at line 12,15,16? so which makes a total of 5 objects

thanks and regards
 
Naveen Madarapu
Ranch Hand
Posts: 64
Eclipse IDE Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
here all references are pointing to one object that is created on line 11

you are assign the all account references to object created on line 11 only.
in line 15 and 16 are pointing same password object.....
 
Ash Gill
Ranch Hand
Posts: 71
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Naveen Madarapu wrote:here all references are pointing to one object that is created on line 11

you are assign the all account references to object created on line 11 only.
in line 15 and 16 are pointing same password object.....


hi naveen, if you look at it from this way: the password is an instance variable of type Long which is an Object.
at line 15: password is given a long value which is autoboxed to a Long object and assigned to password reference variable. so one new Long object through autoboxing.
at line 16: the same password reference variable is assigned another long value which is autoboxed and converted to a Long. so another new Long object created there.

which makes it 2 long objects inside go . please correct me whereever i am wrong.

 
Naveen Madarapu
Ranch Hand
Posts: 64
Eclipse IDE Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
totally create 4 objects it's correct 1)Banker 2)Account 3)acctNum 4) password

if having any grammatical mistakes please let me know English is not my first Language
 
Ash Gill
Ranch Hand
Posts: 71
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hi naveen,



naveen i still thing there is a Long object being created at this line as the right hand side returns a long value which is then autoboxed to a Long and assigned to the password reference variable.

again on line 16:



a Long object is being created on the Right hand side of the expression.

can anyone please give a second opinion?
 
Naveen Madarapu
Ranch Hand
Posts: 64
Eclipse IDE Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
in line 15 is ok...

in line 16 object of type Long contains a single field whose type is long
you are assigned literal to already existed object field.
 
Ash Gill
Ranch Hand
Posts: 71
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Naveen Madarapu wrote:in line 15 is ok...

in line 16 object of type Long contains a single field whose type is long
you are assigned literal to already existed object field.


Naveen the variable 'password' is of type Long so the literal long '4455L' assigned at line 16 is autoboxed to an object Long, isn't it? if so, then a new long object is created through autoboxing.

 
Naveen Madarapu
Ranch Hand
Posts: 64
Eclipse IDE Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
in line 16 reference pointed to already existed Object
if you are assign to another reference. at that time new object will be created.
 
nitin sethi
Ranch Hand
Posts: 59
Android Eclipse IDE Java
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ash Gill wrote:
Naveen Madarapu wrote:here all references are pointing to one object that is created on line 11

you are assign the all account references to object created on line 11 only.
in line 15 and 16 are pointing same password object.....


hi naveen, if you look at it from this way: the password is an instance variable of type Long which is an Object.
at line 15: password is given a long value which is autoboxed to a Long object and assigned to password reference variable. so one new Long object through autoboxing.
at line 16: the same password reference variable is assigned another long value which is autoboxed and converted to a Long. so another new Long object created there.

which makes it 2 long objects inside go . please correct me whereever i am wrong.



Hi Ash,

The below is the quote from JLS 3.0.

If the value p being boxed is true, false, a byte, a char in the range \u0000 to
\u007f, or an int or short number between -128 and 127, then let r1 and r2 be
the results of any two boxing conversions of p. It is always the case that r1 ==
r2.
DISCUSSION
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 characters and shorts, as well as integers
and longs in the range of -32K - +32K.


The line: "Less memory-limited
implementations might, for example, cache all characters and shorts, as well as integers
and *longs* in the range of -32K - +32K" is the key here. It seems even longs are cached for less memory-intensive implementations!! So, that makes the references a1.acctNum and a3.password in the lines 12 and 15 refer to the same Long object.

So, i think the objects eligible for gc in case of more memory-intensive implementation( without caching ) would be 5 and for less memory-intensive, it would be 4.
So, what is the answer we should choose now?


 
Ash Gill
Ranch Hand
Posts: 71
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi nitin,

thanks for replying.

the K&B book says that:
In order to save memory, two instances of the
following wrapper objects (created through boxing), will always be == (means the two wrapper instances would be the same) when their
primitive values are the same:
■ Boolean
■ Byte
■ Character from \u0000 to \u007f (7f is 127 in decimal)
■ Short and Integer from -128 to 127


although they don't mention Long here, but even if we consider Long as well, the range for which two wrapper instances would be same should be -128 to 127. This means anything greater than 127 should definitely be a new wrapper instance (object) and in our case the value is 1024L, much larger than 127. So at line 15, a new wrapper instance Long (1024) should be created. what do you think?

*longs* in the range of -32K - +32K"
what range is this? is it from -32000 to 32000? if it is so in case of longs, then according to
This ensures that in most common cases, the behavior will be the desired one, without
imposing an undue performance penalty
we should always choose memory saving option i.e. 4.
 
nitin sethi
Ranch Hand
Posts: 59
Android Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

In order to save memory, two instances of the
following wrapper objects (created through boxing), will always be == (means the two wrapper instances would be the same) when their
primitive values are the same:
■ Boolean
■ Byte
■ Character from \u0000 to \u007f (7f is 127 in decimal)
■ Short and Integer from -128 to 127


Even I was following the above lines religiously. However, your question and the given answer combined with the lines under the topic DISCUSSION from the JLS opens up everything. 32K means 32000 only.

We need a help here from someone having an in-depth knowledge of the topic of discussion. Anyways, the caching of the value 1024L can only explain the answer given!! Lets wait for someone to throw more light on this.
 
Ash Gill
Ranch Hand
Posts: 71
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
yes, true. we should wait for someone to answer.
However, your question and the given answer combined with the lines under the topic DISCUSSION from the JLS opens up everything. 32K means 32000 only.


also, its not so clear to me if they mean this range only for long or for both long & int.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic