garbage collection

[bairava surya]

class gb
{
   Short e=20;
  gb go(gb e)
    {
    e=null;return e;
    }
   public static void main(String...i)
     {
       gb k=new gb();
       gb s=new gb();
       gb x=s.go(s);
       
       k=null;
    }
}

can help me how many objects eligible for garbage collection?

[Deepak Lal]

The answer is 2

[Henry Wong]

Please QuoteYourSources

Henry

[Roel De Nijs]

bairava surya wrote:can help me how many objects eligible for garbage collection?

What do you think is the correct answer? And why?

[bairava surya]

After k=null three objects are eligible for garabage collection as each object has Short(wrapper class) x ,k,and Short in k object also eliglible. I got this question from kathy sierra scjp!

[Henry Wong]

bairava surya wrote:After k=null three objects are eligible for garabage collection as each object has Short(wrapper class) x ,k,and Short in k object also eliglible.

Hint #1: You have to track the objects, and not the references. It is the objects that get collected (and not references).

Hint #2: The Short references in the code are a ruse. Remember that autoboxing shorts does go through a cache.

Henry

[Guillermo Ishi]

Henry Wong wrote: Remember that autoboxing shorts does go through a cache.

What does that mean?

[Roel De Nijs]

Guillermo Ishi wrote:

Henry Wong wrote: Remember that autoboxing shorts does go through a cache.

What does that mean?

In short: when you use the autoboxing feature, frequently used values (in a given range) are guaranteed to be cached (in an internal cache). These internal caches help to avoid creating redundant objects for frequently used values (like the String constant/literal pool). This caching mechanism is only guaranteed for the following values:

Boolean

Byte

Character from \u0000 to \u007f (7f is 127 in decimal)

Short and Integer from -128 to 127 (inclusive)

A more detailed explanation (with examples) can be found in this post and this follow-up post (in the same thread).

[Roel De Nijs]

Roel De Nijs wrote:This caching mechanism is only guaranteed for the following values:

Boolean

Byte

Character from \u0000 to \u007f (7f is 127 in decimal)

Short and Integer from -128 to 127 (inclusive)

So the correct answer of this example (using Short e=20; as instance variable) will be different than if the instance variable would have been Short e=200; (as explained in great detail here).

[Guillermo Ishi]

I think I remember this now. So what's being said is that being eligible to be cached keeps an Object from being made eligible for garbage collection?

[Roel De Nijs]

Guillermo Ishi wrote:I think I remember this now. So what's being said is that being eligible to be cached keeps an Object from being made eligible for garbage collection?

Yes, because the cache will always keep a reference to the object (which is by the way only created just once, when the primitive wrapper class is loaded). This of course only applies if you use the autoboxing feature or the valueOf method with the primitive parameter, in all other scenarios the object is not cached.

Cached:

Integer i1 = 10;
Integer i2 = Integer.valueOf(10);

Not cached:

Integer i1 = new Integer(10);
Integer i2 = new Integer("10");
Integer i3 = Integer.valueOf("10");

[Guillermo Ishi]

Roel De Nijs wrote:
Yes, because the cache will always keep a reference to the object (which is by the way only created just once, when the primitive wrapper class is loaded). This of course only applies if you use the autoboxing feature or the valueOf method with the primitive parameter, in all other scenarios the object is not cached.

Looks like two of those wonderful Java consistencies I love in one - only if you use the primitive wrapper and only certain primitive types.

There's a technique testees can use to remember arbitrary lists like the certain primitive types above, known as Memory Palace. You can look it up. It's based on visual memory being the strongest. Kind of weird but effective. I use it to remember long, float, double, and boolean for switch blocks.

[Roel De Nijs]

Guillermo Ishi wrote:I use it to remember long, float, double, and boolean for switch blocks.

I assume you mean you can't use these types in a switch block (statement).

[Guillermo Ishi]

It's a shorter list to remember than the types you can use.

[Roel De Nijs]

Guillermo Ishi wrote:It's a shorter list to remember than the types you can use.

True! But that's only inside your head If you don't know you are listing the invalid data types, that statement could be misleading/confusing.

[Guillermo Ishi]

Ok, for anybody who might see this, those were the invalid data types...

[Ray Kolbe]

Roel De Nijs wrote:

Guillermo Ishi wrote:I think I remember this now.  So what's being said is that being eligible to be cached keeps an Object from being made eligible for garbage collection?

Yes, because the cache will always keep a reference to the object (which is by the way only created just once, when the primitive wrapper class is loaded). This of course only applies if you use the autoboxing feature or the valueOf method with the primitive parameter, in all other scenarios the object is not cached.

Cached:

Integer i1 = 10;
Integer i2 = Integer.valueOf(10);

Not cached:

Integer i1 = new Integer(10);
Integer i2 = new Integer("10");
Integer i3 = Integer.valueOf("10");

I need a bit of clarification here. Are we talking about SE7 here or SE8 or both? Although this is good information to learn is it relevant to 1Z0-808?

Roel you say in another post in this thread:

Roel De Nijs wrote:
This caching mechanism is only guaranteed for the following values:
Boolean
Byte
Character from \u0000 to \u007f (7f is 127 in decimal)
Short and Integer from -128 to 127 (inclusive)

It appears this is different in SE8.

Per JLS (https://docs.oracle.com/javase/specs/jls/se8/html/jls-5.html#jls-5.1.7):

If the value p being boxed is an integer literal of type int between -128 and 127 inclusive (§3.10.1), or the boolean literal true or false (§3.10.3), or a character literal between '\u0000' and '\u007f' inclusive (§3.10.4), then let a and b be the results of any two boxing conversions of p. It is always the case that a == b.

Whereas SE7 JLS (http://docs.oracle.com/javase/specs/jls/se7/html/jls-5.html#jls-5.1.7):

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.

Furthermore it looks like "valueOf" with a string param works differently in SE8.

Example

Integer t = Integer.valueOf(126);
Integer u = Integer.valueOf("126");
System.out.println("Integers are equal: " + (t == u));

I get back "Integers are equal: true". I've tried changing "t" to "Integer t = 126" and I get the same output. It's only when I do "Integer t = new Integer(126)" that I get "false".

[Ray Kolbe]

Re: my last post, the difference between SE7 and SE8 appear to be that short is not cached, unless that language is buried somewhere else.

[Ray Kolbe]

Perhaps the JLS is wrong since this appears to be cached:

Short t = Short.valueOf((short)126);
Short u = Short.valueOf("126");
System.out.println("Integers are equal: " + (t == u));

My other questions still stand  

[Ray Kolbe]

Ah shoot. I actually meant to post these replies to https://coderanch.com/t/661830/ocajp/certification/Garbage-Collection which links to *this* thread. I've made a mess of things  

[Paul Clapham]

I dunno... what you've posted seems to go pretty well with the rest of the thread. Sure the thread was a year old, but that's not a big deal.

I could split off your posts and attach them to the other thread you linked to, but it wasn't talking about numeric wrapper types anyway so they wouldn't really match. On the whole I think your posts are actually better here.

And I'll give you a cow for doing the research.