On 4/14/16 10:26 PM, Dr Heinz M. Kabutz wrote:
Vladimir Ivanov wrote:
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.
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.
Vladimir, Heinz,
Thanks for thinking about this. I'd love to see EA improved. It might be
possible to do so without any changes to the specs... but we can also change the
specs, within limits, if it will make it easier to do EA or other optimizations.
I'll note that in Integer.valueOf(), the cache range is from -128 to 127
inclusive. The lower bound is a constant, but the upper bound is set by a
property and thus isn't a constant! This is set by -XX:AutoBoxCacheMax and also
by -XX:+AggressiveOpts I think. Would turning the upper bound into a compile
time constant make things any easier? It's not clear to me the ability to set
the cache range is of any use.
In any case the main goal here is to pave the way toward value objects, and to
get their full benefit, code needs to migrate away from constructs that expose
the identity of the boxed values. This applies to all of the boxed primitives.
s'marks
