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
