Migration of Integer to inline

[Remi Forax]

----- Mail original -----
> De: "Mateusz Romanowski" <romanowski.mateusz at gmail.com>
> À: "Brian Goetz" <brian.goetz at oracle.com>
> Cc: "valhalla-dev" <valhalla-dev at openjdk.java.net>
> Envoyé: Samedi 21 Décembre 2019 01:17:31
> Objet: Migration of Integer to inline

> True.
> Sorry for being unclear, but I wanted to point out that not only *dusty*
> but *current* classfiles as well might contain Integer::new invocations.
> 
> I found once that replacing Integer::valueOf (1) reference with deprecated
> Integer::new (2) made quite a difference as current JIT elided boxing
> (through scalarization) only for (2).
> I was quite surprised at that time how going through cache kills
> performance..

This was fixed recently
see https://bugs.openjdk.java.net/browse/JDK-8075052

Anyway i agree with you, most of the existing code is still using new Integer() because this constructor was only deprecated in 9 and not a lot applications have not yet migrated to 11, so most people are unaware that those constructors have been deprecated. 

We should have a way to backport @Deprecated (seen as future deprecation).

Rémi

> 
> W dniu sobota, 21 grudnia 2019 Brian Goetz <brian.goetz at oracle.com>
> napisał(a):
>> If we can successfully migrate Integer to be a value type, the cache goes
> away, since the instances no longer have identity.
>>
>> On 12/20/2019 6:11 PM, Mateusz Romanowski wrote:
>>
>> Thanks for quick response.
>>
>> As for Integer::new, some people (including me once) might still use the
> constructor to bypass the IntegerCache.
>>
>> The migration story could then include some Integer::valueOfUncached
> factory for such usages.
>>
>> I would love to see such method introduced with the constructor being
> made synthetic (JDK-8236444).
>>
>> Cheers.
>>
>>
>> W dniu piątek, 20 grudnia 2019 Brian Goetz <brian.goetz at oracle.com>
> napisał(a):
>>>
>>>
>>>> If non-Object abstract class as superclass of inline class is allowed,
> the
>>>> migration story for Optional seems easy.
>>>> It would be the same for Integer, if only there were no pesky public
>>>> Integer::new...
>>>
>>> These constructors have been deprecated since Java 9; and there has been
> IDE support for migrating invocations of these to the appropriate factory
> methods for at least a dozen years.  It is reasonable to deprecate them for
> removal.
>>>
>>> As with `new Object()`, it is also possible to take heroic measures to
> relink `new Ljava/lang/Integer;` bytecodes to instantiate some other type,
> though we're not ready to plunk for that yet (it's more complicated than
> for Object.)
>>>
>>> Bytecode weaving (perhaps even at load time, with an agent) is indeed a
> possible means of rewriting these dusty jars.
>>>
>>>>
>>>> Could you share any preliminary thoughts how the classfiles (found in
>>>> *dusty* jars) that use the Integer constructor would be treated?
>>>>
>>>> Is it feasible to have the bytecode weaved to replace the new-dup-init
>>>> sequence during class loading?
>>>>
>>>> Thanks,
>>>> Mateusz
>>>
>>>