The 0.26.0 release of Eclipse OpenJ9 includes updates that improve startup times for Open Liberty servers that run in development mode. This post looks at the changes behind those improvements and how you can take advantage of them.
Open Liberty development mode, or dev mode, enhances the developer experience by providing hot reload and deployment, on-demand testing, and debugger support. OpenJ9 is a scalable, high-performance, Java virtual machine (JVM) implementation. One of the biggest benefits of OpenJ9 is fast startup, thanks to the Shared Classes Cache (SCC) feature, which contains both classes and previously (dynamically) compiled Ahead-of-time (AOT) Code. AOT Compilation in OpenJ9 is the process of compiling code in one JVM instance to reuse it in another JVM instance. When you use a Java SDK with the OpenJ9 VM to run Open Liberty, the VM feature that enables dev mode is called Full Speed Debug (FSD). Before OpenJ9 version 0.26.0, the VM did not have AOT support for FSD. Therefore, Open Liberty dev mode did not benefit from the fast startup that normally comes with OpenJ9. However, from version 0.26.0 onward, FSD support is added for AOT compilations, and Open Liberty dev mode gets a boost in startup time from the SCC.
How did this improvement occur? First, a significant improvement was made in FSD performance when FSD is implemented with another feature known as OSR. This new implementation naturally facilitated generalization to relocatable compilations. The main idea behind FSD is, if a debug event occurs, an application thread moves from the middle of a compiled body to the interpreter. This transition ensures that compiled code can be highly optimized because the compiler does not need to worry about the consequences of debug events. When no more debug events exist, the application thread is allowed to run compiled code again.
Adding AOT support boiled down to ensuring that all the OSR data in the compiled body’s metadata and any breakpoint guards can be relocated. The OSR data is needed to ensure the transition from the compiled code into the interpreter. The breakpoint guards are needed to ensure that debug events are respected when a method gets inlined. Other subtleties are involved regarding relocations, which you can read about in the previously cited pull requests. However, the practical impact of these changes is a noticeable difference in the user experience of dev mode.
To give a more objective description of the improvement, I ran dev mode on the DayTrader7 benchmark application and I observed that the startup time was roughly halved. I measured this improvement by starting and stopping an Open Liberty server that was running on 4CPUs, without measuring the startup time for the first run. The first time dev mode runs with OpenJ9 0.26.0, it seems slower because the first run generates all the AOT code that is placed in the SCC. All subsequent invocations of dev mode are noticeably faster.
To conclude, I recommend upgrading your Java SDK to use OpenJ9 0.26.0 so you too can benefit from a drastic improvement in Open Liberty dev mode performance with OpenJ9.