Ahead of Time Compilation for the Java Virtual Machine

Summary

Enhance the Java Virtual Machine with the ability to load Java applications and libraries compiled to native code for faster startup and baseline execution.

Goals

Enable the Java Virtual Machine to load Java code compiled Ahead of Time to native code, if it was compiled by a compiler from a matching Java Virtual Machine. Allow C1, C2, and JVMCI Compilers to code native code Ahead of Time for a Java Virtual Machine to use. "Profiling" code is code compiled by C1 in tiers 2 and 3 for use as baseline execution and profiling, while "Optimized" code is heavily optimized code produced by C1 in tier 1, C2, or any compatible JVMCI compiler for use as permanent, always optimized code that executes outside the Tiered Compilation model and is hence not subject to optimization and deoptimization cycles.

Non-Goals

It is not a goal to support this feature for code that violates the constraints that Leyden places on its closed world binaries counterpart.

Success Metrics

Java applications, libraries (including Java standard libraries), and any pluggable Java Virtual Machine components written in Java (such as any JVMCI Compilers) should be able to be compiled Ahead of Time to native code, in either profiling or optimized modes, and be loaded in a matching Java Virtual Machine with high baseline performance, bypassing the Interpreter and, based on the mode it was compiled in, C1 or C2 compilation entirely.

Motivation

Java applications and libraries are currently executed in a customizable three stage model, first at Tier 0 in the Interpreter, at Tier 3 as C1 compiled code, and at Tier 4 as C2 compiled code, with Tiers 1 and 2 being special-cased C1 compiled code. This process is very dynamic, involving many iterations of optimization and deoptimization cycles over the course of the code's lifetime. Additionally, this also means that code warmup (where execution of code instruments compiling a highly optimized version) can take a long time, causing performance issues in applications, some of which can be critical, meaning such issues are not acceptable.

A good example is the Graal Compiler, which used to be an available replacement for C2 prior to Java 17. The bootstrapping stage when the compiler was started up affected the entire application negatively, as Graal itself had to be compiled before it could operate reasonably, something which negated the possible performance gains it brought significantly.

Additionally, the deoptimization process that occurs when C2 compiled code hits an incorrect assumption can also be costly, given that the profiling C1 variant has to again be recompiled when this happens, only to be discarded again once C2 recompiles the same method. This, combined with the issues described above, can be wasteful. A good solution to this would be to have a permanent Ahead of Time C1 compiled variant of the method replace the Interpreter and all runtime C1 compilation, such that on startup, execution begins with the precompiled C1 code and then immediately progresses to C2 compilation, bypassing some of the warmup steps, as well as the Interpreter, entirely.

This also means that deoptimization can immediately fall back to the C1 compiled code rather than all the way down to the Interpreter, and that no C1 nmethods have to be discarded once the C2 variant is installed, instead remaining as a deoptimization target should it happen.

With Galahad once again reintroducing potential Ahead of Time Compilation for the JIT Compiler it plans to integrate into the JDK, it is also advantageous to consider such a feature, for Galahad to have a ready platform for loading a precompiled Compiler into the VM.

Description

// REQUIRED -- Describe the enhancement in detail: Both what it is and, // to the extent understood, how you intend to implement it. Summarize, // at a high level, all of the interfaces you expect to modify or extend, // including Java APIs, command-line switches, library/JVM interfaces, // and file formats. Explain how failures in applications using this // enhancement will be diagnosed, both during development and in // production. Describe any open design issues. // // This section will evolve over time as the work progresses, ultimately // becoming the authoritative high-level description of the end result. // Include hyperlinks to additional documents as required.

Alternatives

Currently, the only Ahead of Time Compiler alternatives are GraalVM native-image and Leyden's closed world Java executables. Both produce closed world, standalone binaries which are not in any way related to the execution of Java applications by the Java Virtual Machine, HotSpot. The jaotc compiler was another Ahead of Time Compiler produced by the GraalVM, but has since been removed in Java 17 due to lack of use. We do not wish to make this feature specific to Graal, as is the case with the jaotc compiler, instead the code is to make code compiled by C1, C2, or any JVMCI Compiler available for use by the VM Ahead of Time.

Testing

// What kinds of test development and execution will be required in order // to validate this enhancement, beyond the usual mandatory unit tests? // Be sure to list any special platform or hardware requirements.

Risks and Assumptions

// Describe any risks or assumptions that must be considered along with // this proposal. Could any plausible events derail this work, or even // render it unnecessary? If you have mitigation plans for the known // risks then please describe them.

Dependencies

// Describe all dependencies that this JEP has on other JEPs, JBS issues, // components, products, or anything else. Dependencies upon JEPs or JBS // issues should also be recorded as links in the JEP issue itself. // // Describe any JEPs that depend upon this JEP, and likewise make sure // they are linked to this issue in JBS.