RFR(m): 8145468 deprecations for java.lang

[Vladimir Ivanov]

>>> 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