Feedback / query on jextract for Windows 10

[Remi Forax]

----- Mail original -----
> De: "John Rose" <john.r.rose at oracle.com>
> À: "Maurizio Cimadamore" <maurizio.cimadamore at oracle.com>
> Cc: "duncan gittins" <duncan.gittins at gmail.com>, "panama-dev at openjdk.java.net'" <panama-dev at openjdk.java.net>
> Envoyé: Lundi 1 Février 2021 05:35:06
> Objet: Re: Feedback / query on jextract for Windows 10

> On Jan 28, 2021, at 2:05 PM, Maurizio Cimadamore
> <maurizio.cimadamore at oracle.com> wrote:
>> 
>> This approach is fully lazy: the `x` constant is only initialized when
>> the `get_x` method is called, because the constant is defined in its
>> own holder class, and that holder class is only referenced by the
>> getter method. So this is both lazy, and constant-friendly.
> 
> This is one of the use cases for lazy statics.  IMO a compelling
> compilation story would be a new mechanism for tying a
> static final to a condy CP entry, sort of like they are tied to
> CONSTANT_String and CONSTANT_Integer CP entries today.
> 
> But these changes are always expensive and difficult.
> In the case of lazies, we would want to upgrade the JVM
> and the language in tandem.  And we’d want to put in a
> story for lazy non-statics, which is a can of worms.
> 
> One limited way to begin could be to add just the JVM
> feature, just for statics, so that bytecode generator tools
> could use it.  That’s the thrust of JDK-8209964.
> 
> A risk there is that what we would build would be
> not-quite-right for an eventual build-out through
> the language.
> 
> https://bugs.openjdk.java.net/browse/JDK-8209964

[added Claes in CC, because i think it may interest him]

jextract generated classes is one use case, booting the JDK is another one,
the last time i take a look there was something like a little more than 200 static final fields that are initialized by a putfield with no corresponding getfield called when the JDK is initialized,
having those static final fields being lazy initialized can make a huge difference in term of startup speed (for the exact same reason the classes generated by jextract is actually faster that using the generated java files).

For the JDK, maybe as a first step, we can at least rewrite the static final fields that are declared private using a jlink plugin that remove an invokestatic + putfield inside the static init if the field is marked with a special @Lazy annotation and rewrite the corresponding getfield to an accessor method that will do a ldc + constantdynamic with the method called by invokestatic as bootstrap method.

Another intermediary solution is to implement the lazy keyword in the compiler (javac) but only enable it under a flag. So that flag can be used when compiling java.base and jextract generated classes.

For me the non-static lazy is a non problem, Java already considers separately final field and static final field, so lazy can be only allowed on static final fields, but neither on static fields nor on non-static fields.   

> 
> — John

Rémi