RFR(m): 8145468 deprecations for java.lang
Dr Heinz M. Kabutz
heinz at javaspecialists.eu
Fri Apr 15 05:26:03 UTC 2016
Vladimir Ivanov wrote:
>>
>> 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
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 :-)
Stuart, I'm not a great fan of @SuppressWarning() and would personally
prefer the constructors for integer types to stay non-deprecated.
Boolean's constructor is fine to deprecate, as are Double and Float.
Heinz
Heinz
More information about the core-libs-dev
mailing list