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
