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