RFR(m): 8145468 deprecations for java.lang

[Remi Forax]

Hi Heinz,
i think we should go nuclear on this, deprecate the Integer constructor *and* remove the line in the spec that says that Integer.valueOf (and Byte, Short, Character, Long) uses a cache and admit that the Java spec should not have a premature optimization carved in it.

About your example about EA, do you agree that if the set is declared as a Set<int>, there is no such issue anymore ?

Rémi

----- Mail original -----
> De: "Dr Heinz M. Kabutz" <heinz at javaspecialists.eu>
> À: "Vladimir Ivanov" <vladimir.x.ivanov at oracle.com>
> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoyé: Vendredi 15 Avril 2016 07:26:03
> Objet: Re: RFR(m): 8145468 deprecations for java.lang
> 
> 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
>