The OpenJDK project has proposed a new Project - codenamed Galahad - to merge some parts of the GraalVM Community Edition codebase into OpenJDK.
This is the latest development in a long-running effort to provide a capability to compile Java applications to machine code before program execution. On the face of it, this seems somewhat strange - after all, one of the first things that a new Java developer learns is that "Java doesn't compile to machine code, but instead to JVM bytecode".
This simple maxim has deeply far-reaching implications, the most basic of which is that the Java platform relies upon a powerful dynamic runtime - the JVM - for execution. This runtime enables dynamic runtime techniques, such as classloading and reflection, that do not really have analogues in ahead-of-time (AOT) compiled languages. In fact, this is the jumping-off point for so much that is powerful about Java - and what made it so groundbreaking when it arrived on the software scene, 25 or so years ago.
Despite this, there has always been interest in the possibility that Java programs could be directly compiled to machine code and execute standalone without a JVM. There are a few different reasons for this desire - whether it's to reduce the warmup time for Java applications to reach peak performance, to reduce the memory requirements of Java apps, or even just a general desire to avoid using resources for runtime subsystems that an application may not need.
There have been several projects that attempted to realise this possibility. The most recent, and arguably the most successful to date, is the GraalVM project. This project emerged not from OpenJDK but instead from a research propject at Oracle Labs. The first production-grade release, GraalVM 19.0, arrived in May 2019.
Since then it has run as an independent project with a different release cycle and limited interaction with OpenJDK. Two of the few Java Enhancement Proposals (JEPs) that relate to GraalVM are:
- JEP 243: Java-Level JVM Compiler Interface
- JEP 295: Ahead-of-Time Compilation
Both of these JEPs arrived in Java 9 and, together, they introduced the Graal compiler into the OpenJDK codebase.
The Graal compiler is one of the primary components of GraalVM - it is a compiler that operates on Java bytecode and produces machine code. It can operate in either JIT or AOT mode.
In the former, it can be used in place of C2 (sometimes referred to as the "server compiler"). It is important to note that Graal is itself written in Java - unlike the other JIT compilers available to the JVM which are written in C++.
Graal was made available as an experimental Java-based JIT compiler in Java 10, as JEP 317. However, in Java 17 (released in September 2021), the experimental forms of both the AOT and JIT compilers were removed. Despite this, the experimental Java-level JVM compiler interface (JVMCI) was retained - so that it remains possible to use externally-built versions of the Graal compiler for JIT compilation.
The latest announcement will, if delivered as expected, mark the return of Graal to the OpenJDK codebase. However, what is perhaps more significant is the GraalVM process and project changes. Galahad will be run as an OpenJDK subproject and maintain a separate repo that periodically rebases on the mainline repo. When features are ready, they will then be migrated to the mainline repo. This is the same model that has been successfully used by long-running projects such as Loom and Lambda.
Galahad is targeting JDK 20 as the initial baseline. This is essentially a code and technical starting point, as JDK 20 has already entered Rampdown - so there is no possibility of any reintroduced Graal code shipping as part of Java until at least JDK 21 (expected September 2023). For now, Galahad will focus on contributing the latest version of the GraalVM JIT compiler and integrating it as an alternative to C2. Later, some necessary AOT compilation technology will be added in order to make the Graal JIT compiler available instantly on JVM start.
This is necessary because, as Graal is written in Java, it could suffer from a slow-start problem broadly similar to this:
- Hotspot starts with the C1 compiler & Graal available
- Graal is executed on Java interpreter threads and is initially slow until it compiles itself
Pre-compiling the Graal compiler to native code would be one possibility to solve this - an old Draft JEP points the way to this, but it is unknown at this time whether it will be revived or a new effort started.
It should be noted that not all of the GraalVM codebase will be committed - only the core JIT and AOT components, as well as the Native Image tooling. Oracle's proprietary features present in GraalVM Enterprise Edititon are not expected to be donated to the project.
Galahad is starting with an impressive list of committers - not only from Oracle's OpenJDK & GraalVM teams, but also many contributers from the wider OpenJDK community including Andrew Dinn and Dan Heidinga from Red Hat and Roman Kennke from AWS. The precise relationship between Galahad and Project Leyden (another OpenJDK project looking at AOT compilation and related technologies) is yet to become clear, but several of the listed contributors to Galahad have also been active in Leyden.
Despite it still being very early days for the project, many influential community members have welcomed Galahad as representing another important step forward in the quest to keep Java at the forefront of Cloud Native technology stacks.