Project Leyden Delays OpenJDK AOT Compiler, Optimizes JIT Compiler Instead

The goal of Project Leyden is to "address the long-term pain points of Java's slow startup time, slow time to peak performance, and large footprint." It wanted to get there "by introducing a concept of static images" to OpenJDK. Static images result from Ahead-of-Time (AOT) compilation to native executables. After two years with no publicly visible activity, Project Leyden pivoted in May 2022 to first optimize Just-in-Time (JIT) compilation. The "resulting optimizations will almost certainly be weaker" than initially planned, and reach mainstream Java developers at the end of 2025 at the earliest. Oracle's Graal project has already achieved Project Leyden's goal, but at a cost that the project wants to avoid for now.

The Graal project originates in Oracle Labs and is not part of OpenJDK. Its GraalVM Native Image is a Java AOT compiler that produces native executables today. They have four advantages over Java's JIT compiler: fast startup, lower memory and CPU usage, fewer security vulnerabilities, and smaller file sizes.

But these achievements come at a cost: GraalVM Native Image enforces a so-called closed-world assumption on Java applications that eliminates a whole category of Java applications. Why? Because Java is a dynamic language and gives applications a lot of power at runtime, such as reflections, class loading, or even class construction. And some of these features don't work in the closed world of GraalVM Native Image. That's why Project Leyden now wants to "explore a spectrum of constraints, weaker than the closed-world constraint, and discover what optimizations they enable." Still, Leyden "will likely [...] produce fully-static images," though only "in the long run."

OpenJDK Has Previously Tried AOT Compilation

Project Leyden is OpenJDK's second attempt at AOT compilation. The first effort was jaotc with JEP 295, Ahead-of-Time Compilation, delivered in JDK 9 in September 2017. Like GraalVM Native Image, it used the Graal project. Unlike GraalVM Native Image, it was highly unpopular: When Oracle removed jaotc from its Java 16 builds, "no one complained," Oracle drily noted with JEP 410, Remove the Experimental AOT and JIT Compiler, delivered in JDK 17.

Project Leyden has had an unusual history for an OpenJDK project. Java Language Architect Mark Reinhold proposed it in April 2020 followed by OpenJDK having approved it as a project in June 2020. But the project had shown no visible progress in the two years between that approval and the creation of its mailing list in May 2022. That's why the project is just starting, focusing "more upon concepts than code" now. Reinhold stated that components such as "the HotSpot JVM, the C2 compiler, application class-data sharing (CDS), and the jlink linking tool" are targets for optimization. Notably missing from that list was CRaC, an OpenJDK project that reduces startup time by loading the Java application state from disk.

A back-of-the-envelope calculation shows possible delivery dates. LTS releases have now outsized importance in Java. Ben Evans, formerly of monitoring company New Relic, announced at Devoxx UK 2022 that "no non-LTS version has ever passed 1% of market share". This shows that mainstream Java developers only migrate from one Java LTS version to another LTS version.

Since Project Leyden is only now underway, few results will be production-ready in September 2023 for JDK 21, the next LTS release. So mainstream Java developers will likely only see Project Leyden's first results with the LTS release after that, JDK 25, in September 2025. Based on that assumption, Project Leyden would, at the earliest, deliver AOT compilation to native executables with JDK 29 in September 2027. InfoQ will continue to monitor progress on Project Leyden.

Spring Boot Reacts to Project Leyden

At least some of the features considered for Project Leyden, such as jlink or CRaC, require application framework support to work best. That's why InfoQ reached out to developers representing Spring Boot, Quarkus and Micronaut for their initial reaction to the Project Leyden announcement.

Spring Framework project lead, Juergen Hoeller, approves of Project Leyden:

Project Leyden is a promising initiative aligned with the general direction that we are taking in Spring Framework 6 and Spring Boot 3.

Hoeller also embraces CRaC for Spring:

CRaC heap snapshots could become a common option for improving the startup time of Spring-based applications. Taking the snapshot at the very end of the application startup phase, there would be hardly any open file or network resources at that point, in alignment with CRaC's expectations. Spring even resets its common caches at the end of an application context refresh already, clearing startup-related metadata before dynamically repopulating the caches with request-related metadata. In terms of [...] the application context specifically reacting to a snapshot event or improving the "snapsafety" of common components, we will certainly try to empower early adopters as far as technically feasible within our Spring Framework 6.x line.

Hoeller thinks that Spring will support jlink and the Java Platform Module System (JPMS) soon:

The current Spring Framework 6.0 milestones do not include module-info descriptors yet. This is on the roadmap for the M6 milestone in September, re-evaluating the module system readiness of the third-party ecosystem as we move on to our 6.0 release candidate phase. With Project Leyden potentially turning jlink into a more powerful and versatile tool, we intend to prepare not only for jlink's current capabilities but also for its further evolution.

Quarkus Reacts to Project Leyden

Quarkus co-founder and co-lead, Jason Greene, commented on Project Leyden:

We are most excited about the Leyden project's goal to revise the Java Language Specification to better support static images, native compilation, and other technologies such as JVM checkpointing. Further, we were happy to see closed-world remaining as a likely long-term goal for the project.

Greene embraces CRaC for Quarkus:

Initial support for the CRaC research project was recently contributed to the Quarkus project by the CRaC lead. Since Quarkus performs build-time optimization no matter the run-time target type, you still see considerable savings when running on OpenJDK, not just GraalVM. Adding a checkpointing approach, such as CRaC, on top of OpenJDK further optimizes startup time. It does not bring similar memory savings as native images, but it is an interesting future option for applications that prefer or require JVM execution.

However, Greene is more reluctant about jlink and JPMS in Quarkus:

As of today, jlink only brings benefits to the storage overhead of a JVM-based application (memory overhead and startup time are essentially the same without it). However, the common practice in a container or Kubernetes application is to layer on a standard JVM base image, which already brings further savings than switching all applications to jlink (since each would bundle their own trimmed JVM). In the case of a native image, the fine-grained elements of the JVM are compiled into the image, so jlink is not helpful in this scenario as well. Likewise, with JPMS, Quarkus already has the notion of modularity through Quarkus extensions, allowing you to trim your dependency set to only what you need. The approach Quarkus takes is compatible with the simple flat classpath that most of the Java ecosystem and build tools prefer today. On the cost side, moving to a pure JPMS module model as jlink requires (no auto-modules) would mean a breaking change not just to Quarkus but to many of the libraries Quarkus builds on. Before considering a switch, we'd like to see these factors balance out better. 

Micronaut Reacts to Project Leyden

Sergio del Amo Caballero, principal software engineer at Object Computing, Inc. (OCI), had no official Micronaut Framework statement on Project Leyden. But he pointed to a recent GitHub issue for adding CRaC support in Micronaut.

Caballero also shared a YouTube clip from July 2020 featuring Micronaut creator, Graeme Rocher, commenting on JPMS: Micronaut supports JPMS and publishes module-info files, but has "to balance that with supporting Java 8". JPMS was added in Java 9, but Micronaut 3.5, the current version, still runs on Java 8.

Conclusion

So far, OpenJDK hasn't addressed "the long-term pain points of Java's slow startup time, slow time to peak performance, and large footprint." First, its jaotc AOT compiler failed to gain traction and was retired. Then Project Leyden set out to standardize native compilation in Java but stalled for two years.

Now that Project Leyen has pivoted to first optimizing JIT compilation, things are looking up: both Spring and Quarkus embrace CRaC for startup time reduction. But when it comes to smaller Java application sizes, only Micronaut adheres to Project Leyden's suggestion of using the JPMS. Spring plans to support the JPMS in version 6 by the end of 2022, though the Spring ecosystem may not. And Quarkus currently has no plans to add the JPMS.

Results, in the form of JEPs, from Project Leyden could reach mainstream Java developers by the end of 2025 at the earliest. So at least until then, the combination of the GraalVM Native Image AOT compiler with a framework like Quarkus, Micronaut, or the upcoming Spring Boot 3 remains the best option to avoid "Java's slow startup time, slow time to peak performance, and large footprint."