Migration of Integer to inline

[Mateusz Romanowski]

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..

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
>>
>>
>