Call for Discussion: New Project: CRaC

[Dan Heidinga]

Hi,  I'm a little late to the conversation but wanted to add that the
Eclipse OpenJ9 project [1] is interested in collaborating in this area
as well.

We've been exploring implementing a checkpoint/restore mechanism at
the JVM level [2] along with the required language-level Lifecycle
APIs ("hooks") to allow pre-snapshot / post-restore fixups.  Recently,
we've shifted gears to base our efforts on CRIU as the checkpoint
mechanism to make faster progress on the hooks support.  There's
overlap between the various approaches in this space and we see a lot
of benefit to standardizing the language support for saving/restoring
state.

Count us in as interested in engaging in this project.

--Dan

[1] https://github.com/eclipse-openj9/openj9
[2] https://danheidinga.github.io/Everyone_wants_fast_startup/



On Sun, Jul 18, 2021 at 10:49 AM Anton Kozlov <akozlov at azul.com> wrote:
>
> Hi,
>
> It's been a while since we presented Coordinated Restore at Checkpoint for the
> first time [0].  We are still committed to the idea and researching this topic.
>
> Java applications can avoid the long start-up and warm-up by saving the state
> of the Java runtime (snapshot, checkpoint).  The saved state is then used to
> start instances fast (restored).  But after the state was 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.
>
> We believe 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.  The application will
> also be able to obtain uniqueness from the environment.
>
> The CRaC project aims to research Java API for coordination between application
> and runtime to save and restore the state.  Runtime should support multiple
> ways to save the state: virtual machine snapshot, container snapshot, CRIU
> project on Linux, etc.  We hope to come with an API that is general enough for
> any underlying mechanism.  We also plan to explore safety checks in the API and
> runtime, which prevent saving the state if it may not be restored or work
> correctly after the restore.
>
> I propose myself as a Project Lead of the CRaC Project.  If you're interested
> or want to be the committer, please drop me a message.
>
> A fork of JDK [1] would be a starting point of this project.
>
> Thanks,
> Anton
>
> [0] https://mail.openjdk.java.net/pipermail/discuss/2020-September/005594.html
> [1] https://github.com/CRaC/jdk
>