Oracle added the GraalVM Just-in-time (JIT) compiler as an experimental feature to Oracle JDK 23, its OpenJDK distribution, in September 2024. The GraalVM JIT compiler is faster than the standard OpenJDK JIT compiler and easier to maintain. Oracle's move is controversial because it has investigated including the GraalVM JIT compiler in all OpenJDK distributions, not just its own. The state of that investigation is unclear.
Java needs a JIT compiler because the HotSpot JVM interprets Java's machine-independent bytecode at runtime. That is much slower than languages like C++, where the Ahead-of-time (AOT) compiler creates machine code at build time. In Java, the JIT compiler converts the bytecode of often-used methods ("hot spots") into machine code at runtime.
The GraalVM JIT compiler is one result of the Oracle labs project GraalVM, a high-performance runtime for JVM languages like Java, JavaScript, Python, and Ruby. The GraalVM JIT compiler can run inside the standard OpenJDK virtual machine called HotSpot JVM. But it also runs in GraalVM JDK, a Java distribution based on Oracle JDK.
The standard OpenJDK HotSpot JIT compiler is a tiered compiler consisting of the C1 and C2 compilers. Both are written in C++ and have been the default since 2000. The GraalVM JIT compiler has some technical advantages over HotSpot and is written in Java which makes it easier to maintain than the C1 and C2 C++ code. Oracle found that running its cloud business software NetSuite with the GraalVM JIT compiler reduced CPU consumption by 6-7% in general and 13% in some workloads.
GraalVM has a second Java compiler, the Native Image AOT compiler that moves compilation and as much initialization work as possible to build time. It produces native executables that start instantly and have no JIT compiler. Using Profiling-Guided Optimization (PGO), Oracle says that Native Image reaches a peak performance close to the JIT compiler and even exceeds it in some cases.
Using GraalVM Native Image comes at the price of some possibly showstopping constraints that do not affect most Java applications and a more expensive troubleshooting process. Many application frameworks, such as Helidon, Micronaut, Quarkus, and Spring Boot, have supported GraalVM Native Image for years. Some libraries, especially older ones, do not work out of the box but typically do when supplemented with configuration data for Native Image.
Oracle proposed Project Galahad, an OpenJDK project, in December 2022. Its goal is to contribute the GraalVM JIT compiler and GraalVM Native Image "to the OpenJDK Community and prepare them for possible incubation in a JDK main-line release." The project was approved in early 2023 and has had little public activity since then.
In June this year, Douglas Simon from Oracle said, "The goal of the Galahad project is to better align the GraalVM project with OpenJDK and Oracle JDK" and "Galahad is mostly about aligning the development process between the two teams and shouldn't have any significant effect on user-visible features in the GraalVM distro." As of November 2024, it is unclear if Project Galahad will lead to the inclusion of the GraalVM JIT and AOT compilers in future OpenJDK mainline releases - and when that could happen. It is also unknown how the GraalVM JIT compiler in OpenJDK mainline would differ from the one in the Oracle OpenJDK distribution then.
InfoQ reached out to Oracle for comments, but Oracle chose not to participate.
Simon Ritter, Deputy CTO at Azul Systems, was kind enough to answer questions about JIT compilers.
InfoQ: Most OpenJDK distributions ship with the HotSpot C1 and C2 JIT compilers. In your experience, which Java applications under which circumstances benefit from a different JIT compiler?
Simon Ritter: This is difficult to answer definitively. The role of the JIT compiler is to take Java bytecode and convert them to native machine instructions at runtime. The benefit of this is considerably improved application performance compared to simply interpreting the bytecode.
The C1 and C2 JIT compilers were introduced as part of the HotSpot virtual machine back in JDK 1.2 to address Java's reputation as slow. Code is quickly compiled using C1 to give an immediate performance improvement. Later, the code is recompiled using C2 to generate optimized native instructions based on collected profiling data.
Replacing C2 can lead to more highly optimized native instructions, which will deliver better application performance. The level of improvement will depend strongly on what the code actually does. Simple applications will be unlikely to see any improvement in performance, whereas complex applications, perhaps which are numerically intensive, could see big performance gains. Ultimately, the best approach is to test with alternatives and determine which is best for your application.
InfoQ: Azul sells the Prime OpenJDK distribution with the Falcon JIT compiler. How does Falcon work?
Ritter: Falcon is a replacement for the C2 JIT compiler and is based on the open-source LLVM compiler project. LLVM is a collection of modular and reusable compiler and tool chain technologies. Much of its work is about taking intermediate representation of compiled code together with profiling data to generate optimal native machine instructions. Azul used this and integrated it into the JVM to work in conjunction with other aspects, such as the garbage collector, class loader, and so on. This work was then contributed back to the LLVM project.
The use of LLVM for JIT compilation allows for different performance characteristics, using techniques like more aggressive speculative optimizations and better auto-vectorization, to name two. This can often deliver double-digit performance improvements
InfoQ: How does the Falcon JIT compiler compare to the C2 and the GraalVM JIT compilers?
Ritter: C2 was introduced in 1998 and is monolithic in its design; it is hard to modify to deliver performance improvements. Falcon, being based on LLVM, is modular, so adding new compilation features is much easier.
The Graal JIT compiler is written in Java. Again, this provides easier ways to modify how it generates code and improve optimizations. The Graal JIT compiler is not currently included in OpenJDK and is only available with the Oracle JDK as an experimental feature
InfoQ: How do Java JIT compilers fare against JIT compilers in other languages, such as .NET or JavaScript?
Ritter: Again, this is a hard question to provide a definitive answer. Probably the best response is to look at the popularity of JVM-based applications on the server-side compared to .NET and JavaScript. The JVM is incredibly scalable and robust, which is why almost all enterprise mission-critical applications choose this platform.
