Migration of Integer to inline
romanowski.mateusz at gmail.com
Sat Dec 21 00:17:31 UTC 2019
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
W dniu sobota, 21 grudnia 2019 Brian Goetz <brian.goetz at oracle.com>
> 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).
> W dniu piątek, 20 grudnia 2019 Brian Goetz <brian.goetz at oracle.com>
>>> If non-Object abstract class as superclass of inline class is allowed,
>>> migration story for Optional seems easy.
>>> It would be the same for Integer, if only there were no pesky public
>> 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
>> 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
>> 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?
More information about the valhalla-dev