garbage collection question k&b practice exam 3

[Ash Gill]

hi friends,

i found this question doubtful, can anyone please explain:

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

4. class Account { Long acctNum, password; }
5. public class Banker {
6. public static void main(String[] args) {
7. new Banker().go();
8. // do more stuff
9. }
10. void go() {
11. Account a1 = new Account();
12. a1.acctNum = new Long("1024");
13. Account a2 = a1;
14. Account a3 = a2;
15. a3.password = a1.acctNum.longValue();
16. a2.password = 4455L;
17. } }

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]

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]

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]

totally create 4 objects it's correct 1)Banker 2)Account 3)acctNum 4) password

4. class Account { Long acctNum, password; }  
5. public class Banker {  
6. public static void main(String[] args) {  
7. new Banker().go();  // first Banker object created here
8. // do more stuff  
9. }  
10. void go() {  
11. Account a1 = new Account();  //Second Account Object with acctNum and password references
12. a1.acctNum = new Long("1024");  //third object here assigned to acctNum 
13. Account a2 = a1;  //second Object reference(a1) assigned to another reference i.e a2
14. Account a3 = a2;  //here a2(this having a1) reference assigned to a3 so a3 also point to a1
15. a3.password = a1.acctNum.longValue();  //4 Object here return long value assigned to a3
// password reference (a3 point to a2 and a2 point to a1) so a1 Object password reference assigned 
// by this Object 
16. a2.password = 4455L;//  here you are assigned to Long value to same a1 Object password
// reference so before assigned value will be losted.
17. } }  

if having any grammatical mistakes please let me know English is not my first Language

[Ash Gill]

hi naveen,

15. a3.password = a1.acctNum.longValue();  //4 Object here return long value assigned to a3  
// password reference (a3 point to a2 and a2 point to a1) so a1 Object password reference assigned   
// by this Object 

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:

16. a2.password = 4455L;//  here you are assigned to Long value to same a1 Object password  
// reference so before assigned value will be losted. 

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

can anyone please give a second opinion?

[Naveen Madarapu]

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]

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]

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]

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]

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]

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]

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.