ARN

Java state API would speed app start-up

OpenJDK proposal would eliminate the long start-up times of Java applications by saving the state of the Java runtime and using it to start instances fast.

Java would be fitted with an API to save state, under a proposal floating in the OpenJDK community as a way to speed up startup times.

Proposed in an OpenJDK discussion group by Anton Kozlov, senior software engineer at Java software provider Azul, the CRaC (Coordinated Restore at Checkpoint) project would research a Java API for coordination between an application and runtime to save and restore state.

According to the proposal, the Java runtime would support multiple ways to save the state: virtual machine snapshot, container snapshot, the CRIU (Checkpoint/Restore In Userspace) project on Linux, and other ways.

Java applications can avoid the long startup and warm-up by saving the state of the Java runtime, the proposal says. Saved state would be used to start instances fast. But the proposal also cites challenges.

After state has been saved, the execution environment could change. Also, if multiple instances are started from the saved state simultaneously, they should obtain some uniqueness and their executions should diverge at some point.

The proposal states that the practical way to solve these problems is to make Java applications aware of when the state is saved and restored. Then an application will be able to handle environmental changes. Additionally, the application will be able to obtain uniqueness from the environment.

Under the proposal, an API would be devised that is general enough for any underlying mechanism. Also, safety checks would be explored in the API and runtime that would prevent the saving of state if it may not be restored or work correctly after the restore.

The expectation is that the API would be developed under the JEP (JDK Enhancement Proposal) process and fitted into standard Java, but no specific version of Java has yet been targeted for the API. The feature set of the upcoming version of Java, JDK 17, due in September, has already been frozen.

In one comment on the proposal, it was suggested that the effort could be synced with a similar proposal at Red Hat. Possible synergies with Project Leyden, to address Java pain points, also were noted.

To smooth the adoption of the API, plans call for making available an org.crac compatibility library. This library would enable the use of the CRaC API before it appears in the mainline JDK.

When running on a JDK version that does not support CRaC or the API, the org.crac API layer would act as a “no-op” layer that does nothing useful, but when running on a JDK version that includes CRaC capabilities, the functionality would be exposed and usable through the org.crac APIs, with no changes required to the API-using code. 

Thus the org.crac API layer would allow adopters to start coding to the CRaC APIs without requiring them to build separate versions of their software that would only work on prototypes or on JDKs from a future version.