RFR(m): 8145468 deprecations for java.lang

[Vladimir Ivanov]

>
> On 4/14/16 7:37 AM, Dr Heinz M. Kabutz wrote:
>> in previous versions of Java, escape analysis did not seem to work
>> particularly
>> well with Integer.valueOf(int) values, since the objects of course
>> could come
>> from the Integer Cache.  Thus if the Integer object did not escape
>> from your
>> method, it could get eliminated entirely.  Not exactly sure what
>> -XX:+EliminateAutoBox does, but my guess would be that there is some
>> relation
>> here.  So even though your changes look sensible, I'm just worried about
>> deprecating the constructors taking a primitive as a parameter.  I
>> haven't
>> looked at this particular issue for a number of years, so it's
>> entirely possible
>> that it is a non-issue now :)
>
> Hi Heinz,
>
> 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.

Best regards,
Vladimir Ivanov

>
> But there are a few things to note.
>
> We're proposing to deprecate the boxed primitive constructors, but *not*
> for removal. This encourages people to migrate their code away from the
> constructors. There's no intent at the present time to remove the
> constructors.
>
> I believe it's still preferable for general-purpose programming to use
> autoboxing or valueOf() in preference to the constructors.
>
> For situations that are extremely performance critical, one can still
> use the constructor. The only difference is that this will generate a
> warning. I'd say that anyone who understands EA and who knows when
> calling the constructor will make a difference will also know how to add
> @SuppressWarnings in the right place.
>
> Of course, these people will suffer when value types come along. :-)
>
> I took a quick look through the valueOf() changes, and it doesn't look
> like any of these are really performance critical. Indeed, most of them
> create the boxed values for the purpose of storing into a field of
> reference type or into a collection, so an object will always have to be
> allocated on the heap. The EA issue doesn't apply to these cases;
> indeed, valueOf() is probably preferable for these cases, in order to
> benefit from the box caches.
>
> This is a good issue to keep an eye out for, though. Thanks for
> mentioning it.
>
> s'marks