CFV: New Project: CRaC

[Andrew Dinn]

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.

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