The OpenJDK proposal is to create an API to save the Java runtime state to speed up the startup of Java applications and instances.
The current idea in the OpenJDK community is to provide Java with an API that would allow to save the state, and thus speed up startup times. More precisely, it is Anton Kozlov, senior software engineer at the Java editor Azul, who is behind the proposal in a discussion group.
His project CRaC (Coordinated Restore at Checkpoint) would consist in developing a Java API for coordination between an application and the runtime in order to save and restore its state.
According to the proposal, the Java runtime would support several methods of saving state: either from a snapshot of the virtual machine, from a snapshot of the container, or by relying on the Linux CRIU (Checkpoint/Restore In Userspace) project, plus other methods.
According to the proposal, Java applications can avoid lengthy startups and booting by saving the Java runtime state. The saved state would be used to quickly start instances.
Challenges to meet
But there are also challenges. First, the execution environment may change after the state has been saved. Also, if multiple instances are launched simultaneously from the saved state, they should be treated uniquely and their executions should diverge at some point.
The proposal states that the practical way to solve these problems is to have Java applications know when the state is saved and restored.
An application will then be able to handle environment changes. In addition, the application will be able to achieve environment uniqueness. The proposal includes the design of a sufficiently general API for any underlying mechanism.
In addition, there will be security checks in the API and runtime to prevent saving the state if it cannot be restored or function properly after restoration. It is likely that the API will be developed as part of the JDK Enhancement Proposal (JEP) process and integrated with standard Java, but no specific version of Java has been targeted for the API yet. The feature set for the next version of Java, JDK 17, due in September, has already been frozen.
Synergies with Leyden and a compatible library
A comment on the proposal suggested that this work should be synchronized with a similar proposal under development at Red Hat. Possible synergies with the Leyden project, aimed at solving Java problems, were also mentioned.
To facilitate adoption of the API, the proposal calls for an org.crac compatibility library to be made available. This would allow the CRaC API to be used before it appears in the main JDK.
If running on a version of the JDK that does not support CRaC or the API, the org.crac API layer would act as an inactive “no-op” layer, but if running on a version of the JDK that has CRaC capabilities, the functionality would be enabled and usable via org.crac APIs, with no changes needed to the code using the API.
Thus, the org.crac API layer would allow adopters to start coding for CRaC APIs without having to build separate versions of their software that would only run on prototypes or on JDKs of a future release.
