orchestration of early boot phases of JVM/JDK

[John Rose]

One bit of Leyden cleanup I want to tackle is regularizing
the early phases of JVM/JDK initialization, where the JVM
C++ code loads a small handful of classes, and then calls
a few Java methods, as it also warms up its C++ data
structures (such as JIT queues).

The Java methods are (increasingly) centralized in the
class jl.System.  I think this is a good move; it makes
the special conditions of early bootstrap easier to
understand, by inspecting the Java code.

In the same direction, I am proposing some cleanups to
jl.System and related API points:

https://github.com/openjdk/jdk/pull/21514

Over time, I would like to see LESS C++ code and MORE
Java code responsible for orchestrating the early boot
activities.

Another place where there is (IMO) more C++ code than
we want is in the C++ lists of pre-loaded JDK classes.
I would like to see these lists get shorter, or even
disappear.  Ideally it should be enough (say) to initialize
jl.System and call its “set-init-level” method several
times, from C++, and let the JVM and JDK code do the rest.

I would also like to explore marking JDK classes and
methods with annotations (JDK-private, like Stable)
when those classes and methods have special roles in
the Leyden life cycle, or even the bare Leyden-free
“exploded build” life cycle.  When we pack up the
MethodType table at the end of the Assembly Phase,
or clear out overflowing tables (at the same time),
or when we unpack something in a runtime-startup
method, or when we query the number of processors
(or some other environmental thingy) at the right
moment, if the bootstrap sequence differs between
a bare Leyden-free run, and a run with a big AOT
cache, the difference should be really clearly
marked in the JDK code, not buried in the C++ code.

We are handling all these issues in an ad hoc way
in Ioi’s current JEP One PR.  We should handle them
in a less ad hoc way, slowly putting the relevant
configuration information in the right places.
Eventually (not immediately) we will understand
how to build a user model that is clean and sane
enough for third parties to use as well.

— John