Should the primitive wrappers be lazy Flyweights?

Question

Following on from a discussion earlier today, which observed that autoboxing currently creates new wrappers:
Integer i = 7;
//currently expands to
Integer i = new Integer(7);
//but we probably want it to become
Integer i = Integer.valueOf(7);This got me thinking about this discussion I saw recently:
http://www.cafeaulait.org/oldnews/news2004March16.html
And that made me think about caching and and the Flyweight design pattern [GangOfFour]
Here's the JavaDoc for Integer.valueOf(int):
* Returns a <tt>Integer</tt> instance representing the specified
* <tt>int</tt> value.
* If a new <tt>Integer</tt> instance is not required, this method
* should generally be used in preference to the constructor
* {@link #Integer(int)}, as this method is likely to to yield
* significantly better space and time performance by cacheing
* frequently requested values.
* @param i a int value.
* @return a <tt>Integer</tt> instance representing <tt>i</tt>.
* @since 1.5
public static Integer valueOf(int i) ;
Unfortunately, this method currently just does:
new Integer(i) !
Is the plan to introduce the use of caching here? And if so will autoboxing use it?
Consider this code:
Integer a = 7;
Integer b = 7;
a.equals(b); // TRUE
a == b; // FALSE with the current autoboxing implementationIf you were to do caching for wrappers, and autoboxing were to use valueOf(), then the second comparison would yield "true".
Thinking that through, one obviously can't change the fact that Integer's constructor is public, so it would always be possible to create new Integers that failed the reference equality test.
Integer is not Cloneable but it is Serializatable, so you'd have to implement readResolve().
I don't know if it would be acceptable to have the old Integer.valueOf(String) method return a cached Integer... probably...
Finally, you'd probably want to support an Integer.intern() method, similar to String.intern() so people can resolve Integers they receive from libraries, should they wish to do so.
Naturally everything I've said about Integer can be applied to the other wrapper classes too.
So is any of this stuff planned? The comments on Integer.valueOf(int) seem to suggest that it is, but some insight would be nice.

Answer 1

We're always being told to use 'new' instead of object
pooling, because object creation/deletion is so fast
these days. Supposedly also one day the JVM will be
able to create stack instead of heap objects (under
suitable circumstances), so 'new' will be almost
costless, whereas pooling would be almost impossible
for the JVM to optimize away.I understand what you mean, and I agree with it for most uses. It somewhat misses the point in this instance.
If one goes around creating 'new' objects then '==' must necessarily return 'false' when they are compared. This is not useful behaviour in this case, in particular because Integer and the other wrapper classes are immutable. It defies expectations that two Integer's that are both '7' are not ==.
The real reason I say you missed the point is because the aim of this object pool is not to improve performance, its to get a different behaviour for autoboxed Integers. As such, while saying "it may be faster to create new objects" is an interesting observation, unless you can devise a way to allocate new objects and preserve reference equality, its not really relevant to the question I was trying to ask.
If you do want to think about performance though, here's some thoughts:
I'm not sure whether you'd ever need to garbage collect the cached Integer instances. I'd guess that you could, because you could use weak references in the cache and let the Integer instances be collected once no more code needs them. In pratice a small working set of Integers (and Doubles, Longs etc) would probably always exist because they would be being used by the VM. It would probably even be worthwhile to determine what this working set is, and preload it as a part of the new startup image optimization.
You might simply decide never to cleanup cached Integers. It might work better to just keep them around for the next time someone uses them. My guess would be some large perctentage of the commonly used Integers fall in a range close to zero (+/- 128?), so why not always have these on-hand in the cache? Perhaps high numbers are rarely used, and would be weak references, but low numbers would be strong references and would never be collected?
One would need to measure and tune to really be sure.
If it turns out that 99% of the Integer objects ever allocated are already loaded in the cache, then all you ever pay is the lookup cost. You would never allocate them and never have to garbage collect them. And that's likely to be faster than making them with 'new' no matter how fast the allocator & collector get. You can't beat simply doing no work on the collection side of things!