November 2024 - leyden-dev

orchestration of early boot phases of JVM/JDK
by John Rose 07 Nov '24

07 Nov '24

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

1 0

cleanups to do after JEP 483 push
by John Rose 07 Nov '24

07 Nov '24

Now that our “JEP One” (483) is nearing the target stage, it is time to talk about post-push work. That would be small stuff like bug fixes, refactorings (for tech debt payoff), and API adjustments. The big stuff (JEPs Two and Three for persistent profiles and AOT code) will follow in time. Here’s my current list of possible post-483 cleanups. We don’t need to do them all, nor necessarily in JDK 24. - contract adjustments for stable, and usage corrections - Mat C.’s hook for ending training runs (small API upgrade) - fix for handling signed JARs (minor bug in PIT) - fix for class loader table overflow (minor bug in PIT) - cleanups for bootstrap orchestration (this is open-ended) - clarify user model for integer box cache, when using AOT cache - get rid of the “scratch object” lifecycle in AOT processing Let’s track this “wish list” under [JDK-8343023], please. And start proper RFEs or bugs as each item gets momentum. And, do reply with more suggestions. Bigger, longer range items are welcome also, but let’s keep them distinct in our minds. I’m mainly talking here about stuff that will make JEP One more robust and maintainable, and a better foundation for JEPs Two, Three, and so on. More to follow… — John [JDK-8343023]: https://bugs.openjdk.org/browse/JDK-8343023

1 0

Skeleton code for mapping code cache from CDS
by ioi.lam＠oracle.com 07 Nov '24

07 Nov '24

In follow up to today's Leyden meeting: Here's the skeleton code in the premain branch that allows you to - allocate space from the "cached code" section of the CDS archive - Store pointers to (a) metadata and (b) other objects that are allocated within "cached code" section. These pointers will be automatically relocated during the production run. https://github.com/openjdk/leyden/blob/21640b10188c8bfb414505043110d6da1508… (Note: currently, the AOT-compiled methods are NOT stored in this section, but are stored in a separate file).

1 0

Optimal place for inserting calls to the VM from interpreted java methods
by Mat Carter 05 Nov '24

05 Nov '24

Is there a place to encode calls to the VM in the interpreted methods other than the method prologs? I've recently discovered the interpreted method adaptors which seems like a candidate, but there's no examples of the adaptors calling into the VM. Follows is the rational as to why I'm looking for an alternative to the method prologs The AOTEndTrainingOnMethodEntry feature [1] introduces calls from java methods into the VM (upcalls) when specific methods are entered. The methods are identified via a pattern in a similar manner to the CompileOnly option. Following the initial PR review we’re looking at removing the knowledge of this AOT feature from the compilers/interpreter and introducing a more generic system (RuntimeUpcalls) that can be used by other parts of the VM [2]. In building out the RuntimeUpcalls system we've come across an inefficiency that isn't an immediate problem for this feature, but should another feature use this new system then it's less than optimal. Interpreted code uses a shared method prolog (there are 8 variants for 'regular' methods [more for some special math/zip methods]), the AOTEndTrainingOnMethodEntry feature introduces a further 5 prolog types. When there is a single upcall (eg. AOTEndTrainingOnMethodEntry) to the VM everything is efficient. The inefficiency issue arises as soon as there are two or more upcalls; which upcalls relate to which methods is contained within the RuntimeUpcalls system. When the interpreter examines the method flags they only indicate whether there are any upcalls (but not how many or which ones). As the interpreter can't encode which upcalls should be called in the prolog (without an explosion of new runtime generated prologs), it needs to call the RuntimeUpcalls system which in turn iterates over the upcalls and calls the appropriate ones; the problem is that during that iteration the methods need to be compared against the pattern. So we either pay a memory cost to cache the method to upcall relationships or we pay a performance cost to repeatedly test the method against the pattern. This is not a problem for C1 and C2 as we pay this cost only when the methods are compiled and create the multiple upcalls in those methods, eliminating the need for pattern matching by the RuntimeUpcalls system during method execution Thanks in advance Mat [1] https://github.com/openjdk/leyden/pull/21 [2] https://github.com/macarte/leyden/pull/2

3 3