JEP 483 targeted to upcoming JDK 24 release

[John Rose]

Our first “premain” feature, affectionally called “JEP One”,
is now targeted[1].

[1] https://mail.openjdk.org/pipermail/jdk-dev/2024-November/009645.html

Congratulations to everyone who helped reach this important milestone!

JEP One will provide a firm foundation for a number of interesting
future JEPs, as seen in our EA.  I think Ioi will be preparing a
final version of the PR, which we will re-review and re-test quickly,
and then push during the next day or two.  The conflict level is
small (just one conflict with Lilliput) so we are hopeful the rebase
will work smoothly.

There is some technical debt here to follow up on.  We will be
fixing a small handful of simple JCK failures which we know about,
and any other bugs that crop up at at level P3 or higher.

As a bigger step, we will be simplifying some parts of the
changes for JEP One.  Many simplifications will probably land
in JDK 25.  For example, workarounds avoiding SoftReference
usage will be removed after we get the kinks out of using
SoftReference in the assembly phase (AP).  And the AP heap
walking logic can be made simpler and more robust.

There is a long list of possible cleanups in JDK-8343023[2].

[2] https://bugs.openjdk.org/browse/JDK-8343023

Our big user visible items, probably follow-up JEPs,
will include a simplified workflow (make the AOT config
generation transparent, optionally), persisting of
method profiles from the training run (TR), and persisting
of compiled method code (the “JIT cache”).  All of these
are visible in the Early Access builds, and were demonstrated
last year at JVMLS 2023.

As an independent workflow RFE, I want to get Mat Carter’s
end-of-training hook pushed whenever we think it is ready.
That is https://bugs.openjdk.org/browse/JDK-8335358.  It
is useful whether the workflow as a whole is improved or
kept as it is today.

I am also hoping to clean up and rationalize the boot
sequence of the JVM, the initialization of the First Hundred
classes.  (They are about a hundred, not exactly 100.)  This
is likely to involve more explicit declarations of ordering
conditions inside the JDK source code itself.  We also want
to split one class C into two CA+CR so that C can be
initialized at assembly time and CR can be initialized
at production runtime.  Instead of CR, we might also
double down on runtime-setup methods in CA, but that
precludes the use of final fields in CA, since finals
in CA would be initialized by the assembly phase, and
not revisited at startup.  We are avoiding magic that
makes final variables change, so if a variable needs
to change, it cannot be a final field.  It can be
stable, though; we expect to amend the contract of
stable variables to allow changes during the assembly
phase.

Thanks,

— John