Does primitive wrapper instantiation cause memory allocation in JDK 1.6

Question

From PMD:

IntegerInstantiation: In JDK 1.5, calling new Integer() causes memory allocation. Integer.valueOf() is more memory friendly.

ByteInstantiation: In JDK 1.5, calling new Byte() causes memory allocation. Byte.valueOf() is more memory friendly.

ShortInstantiation: In JDK 1.5, calling new Short() causes memory allocation. Short.valueOf() is more memory friendly.

LongInstantiation: In JDK 1.5, calling new Long() causes memory allocation. Long.valueOf() is more memory friendly.

Does the same apply for JDK 1.6? I am just wondering if the compiler or jvm optimize this to their respective valueof methods.

Answer 1

The same applies for Java SE 6. In general it is difficult to optimise away the creation of new objects. It is guaranteed that, say, new Integer(42) != new Integer(42). There is potential in some circumstances to remove the need to get an object altogether, but I believe all that is disabled in HotSpot production builds at the time of writing.

Answer 2

This holds for Java 6 as well. Try the following with Java 6 to prove it:

System.out.println(new Integer(3) == new Integer(3));
System.out.println(Integer.valueOf(3) == Integer.valueOf(3));

System.out.println(new Long(3) == new Long(3));
System.out.println(Long.valueOf(3) == Long.valueOf(3));

System.out.println(new Byte((byte)3) == new Byte((byte)3));
System.out.println(Byte.valueOf((byte)3) == Byte.valueOf((byte)3));

However, with big numbers the optimization is off, as expected.

Answer 3

In theory the compiler could optimize a small subset of cases where (for example) new Integer(n) was used instead of the recommended Integer.valueOf(n).

Firstly, we should note that the optimization can only be applied if the compiler can guarantee that the wrapper object will never be compared against other objects using == or !=. (If this occurred, then the optimization changes the semantics of wrapper objects, such that "==" and "!=" would behave in a way that is contrary to the JLS.)

In the light of this, it is unlikely that such an optimization would be worth implementing:

1. The optimization would only help poorly written applications that ignore the javadoc, etc recommendations. For a well written application, testing to see if the optimization could be applied only slows down the optimizer; e.g. the JIT compiler.

2. Even for a poorly written application, the limitation on where the optimization is allowed means that few of the actual calls to new Integer(n) qualify for optimization. In most situations, it is too expensive to trace all of places where the wrapper created by a new expression might be used. If you include reflection in the picture, the tracing is virtually impossible for anything but local variables. Since most uses of the primitive wrappers entail putting them into collections, it is easy to see that the optimization would hardly ever be found (by a practical optimizer) to be allowed.

3. Even in the cases where the optimization was actually applied, it would only help for values of n within in a limited range. For example, calling Integer.valueOf(n) for large n will always create a new object.

Answer 4

Most of the time it doesn't matter. Unless you have identified you are running a critical piece of code which is called lots of times (e.g. 10K or more) it is likely it won't make much difference.

If in doubt, assume the compiler does no optimisations. It does in fact very little. The JVM however, can do lots of optimisations, but removing the need to create an object is not one of them. The general assumption is that object allocation is fast enough most of the time.

Note: code which is run only a few times (< 10K time by default) will not even be fully compiled to native code and this is likely to slow down your code more than the object allocation.

Answer 5

On a recent jvm with escape analysis and scalar replacement, new Integer() might actually be faster than Integer.valueOf() when the scope of the variable is restricted to one method or block. See http://stackoverflow.com/questions/2307904/autoboxing-vs-manual-boxing-java/2308042#2308042 for some more details.