RFR(m): 8145468 deprecations for java.lang
vladimir.x.ivanov at oracle.com
Fri Apr 15 11:42:40 UTC 2016
>>> 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
>>> 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
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
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.
More information about the core-libs-dev