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" <he...@javaspecialists.eu> > À: "Vladimir Ivanov" <vladimir.x.iva...@oracle.com> > Cc: "core-libs-dev" <core-libs-dev@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 >
