CFV: New Project: CRaC

[Volker Simonis]

On Thu, Aug 5, 2021 at 11:28 AM Andrew Dinn <adinn at redhat.com> wrote:
>
> Vote: abstain
>
> I don't want to stop this project being created by posting a veto. I
> think it is only right and proper that members should be allowed to
> investigate any important area for innovation uinder the aegis of a
> dedicated project. However, I am unhappy with this vote being called
> without a more clear conclusion to the prior discussion.
>
> Specifically, I believe the summary below fails to highlight the
> critical need for a significant amount of code in the JDK runtime and
> JVM to be involved in receiving and handling checkpoint and restore
> events and, in direct consequence, being party to the the process that
> saves or constructs a restartable runtime state (obvious areas include
> network and file system i/o management, memory management, security
> management, providers of randomness -- i.e. the same areas where GraalVM
> has found it needs to enforce runtime initialization or runtime repair
> of build-time inited state). My concern is that without a close
> involvement of many existing JDK and JVM engineers in the project and a
> strong commitment from them to supporting it the project is very likely
> to fail. I don't believe we have met either of those two requirements yet.
>

Creating an OpenJDK project by itself does by no means guarantee any
success as we can see from the large number of existing long running
or abandoned projects :) But that doesn't mean that we shouldn't be
allowed to try new ones.

While I can see some connections between the proposed project and
GraalVM/StaticJava/Leyden I still think the two topics are distinct
enough to justify a new project. From my understanding
Leyden/StaticJava has a much broader and more general scope in the
sense that it tries to define a new subset of the Java language and
API which is suitable for static compilation. However, at least from
my understanding, it doesn't cover the use case of snapshotting,
cloning and restoring. This project is more narrow in scope in that it
tries to define a simple interface which will allow applications to
react on snapshot/restore events, no matter if they are running in a
full blown JDK or in a static image. I think snapshot/restore
technologies on a level below the JDK/JVM (i.e. on  container/OS
level) are getting increasing traction and it would be nice if the
JVM/JDK as well as the applications could be made aware of these
technologies (in the same way the JDK has already been made, at least
a little bit, container/virtualization aware).

Best regards,
Volker

> On 30/07/2021 20:17, Anton Kozlov wrote:
> > I hereby propose the creation of the CRaC Project with myself, Anton
> > Kozlov,
> > as the Lead and the HotSpot Group as the sponsoring Group.
> >
> > The CRaC (Coordinated Restore at Checkpoint) [1] project will research
> > coordination of Java programs with mechanisms to checkpoint (make an
> > image of,
> > snapshot) a Java instance while it is executing.  Restoring from the image
> > could be a solution to some of the problems with the start-up and warm-up
> > times.  The primary aim of the project is to develop a new standard
> > mechanism-agnostic API to notify Java programs about the checkpoint and
> > restore
> > events.  Other research activities will include, but will not be limited
> > to,
> > integration with existing checkpoint/restore mechanisms and development
> > of new
> > ones, changes to JVM and JDK to make images smaller and ensure they are
> > correct.
> >
> > The existing proof-of-concept implementation based on the OpenJDK [2]
> > will be a
> > starting point of the project.
> >
> > I work at Azul developing JVM and JDK, focusing on bug fixing, support
> > of new
> > platforms, and start-up/warm-up optimizations.  I'm a co-author of
> > JEP-391 and
> > author of the CRaC proof-of-concept implementation.
> >
> > Initial Committers and Reviewers are:
> > Volker Simonis (Committer)
> > Anton Kozlov (Reviewer)
> >
> > Votes are due by Friday, 13 August 2021, 20:00:00 GMT.
> >
> > Only current OpenJDK Members [3] are eligible to vote on this
> > motion.  Votes must be cast in the open on the discuss list.
> > Replying to this message is sufficient if your mail program
> > honors the Reply-To header.
> >
> > For Lazy Consensus voting instructions, see [4].
> >
> > Anton Kozlov
> >
> > [1] https://mail.openjdk.java.net/pipermail/discuss/2021-July/005862.html
> > [2] https://github.com/CRaC/jdk
> > [3] https://openjdk.java.net/census#members
> > [4] https://openjdk.java.net/projects/#new-project-vote
> >
>
> --
> regards,
>
>
> Andrew Dinn
> -----------
> Red Hat Distinguished Engineer
> Red Hat UK Ltd
> Registered in England and Wales under Company Registration No. 03798903
> Directors: Michael Cunningham, Michael ("Mike") O'Neill
>