I had a sidebar with Shipilev on this, and this is indeed still
potentially an issue. Alexey's example was:
set.contains(new Integer(i)) // 1
vs
set.contains(Integer.valueOf(i)) // 2
EA is able to optimize away the allocation in line 1, but the additional
complexity of dealing with the Integer cache in valueOf() defeats EA for
line 2. (Autoboxing pretty much desugars to line 2.)
I'd say it's a motivating example to improve EA implementation in C2,
but not to avoid deprecation of public constructors in primitive type
boxes. It shouldn't matter for C2 whether Integer.valueOf() or
Integer::<init> is used. If it does, it's a bug.
To do that would probably require a change to the Java Language
Specification to allow us to get rid of the IntegerCache. Unfortunately
it is defined to have a range of -128 to 127 at least in the cache, so
this probably makes it really hard or impossible to optimize this with
EA. I always found it amusing that the killer application for EA,
getting rid of autoboxed Integer objects, didn't really work :-)
Still, I'd separate optimization and specification aspects.
This case is neither "really hard" nor impossible to optimize.
What is hard is to ensure the optimization covers all interesting cases
:-)
AFAIK C2 should already do a pretty decent job of eliminating box/unbox
pairs (e.g., Integer.valueOf().intValue()) and the cache is not a
problem here.
What can cause problems is when box identity intervenes. For example,
even for non-escaping objects the runtime has to be able to materialize
them at safepoints. In order to preserve identity invariants, the
runtime has to take into account how the box is created (constructor vs
factory method).
Probably, that's the missing case right now. But there's nothing
insurmountable to fix it - the runtime should just consult the cache in
the rare cases when rematerialization is necessary.
Best regards,
Vladimir Ivanov
