CFV: New Project: CRaC

Andrew Dinn adinn at
Fri Aug 6 09:49:51 UTC 2021

On 05/08/2021 21:06, Anton Kozlov wrote:
> The checkpoint/restore concept does not require that big changes to
> the Java lang.  Two (or more) phases of the Java application
> life-cycle are implicit. The execution of a Java program is the same,
> but it may just pause for a while. It's much different from
> compile-time/run-time separation for static images.

My father had a good friend who frequently relied on the gambit "It's a 
well-known fact that ..." to sway an argument. Well, I am afraid that 
the above assertion about the limited room for things to go wrong thanks 
to a 'simple' save and restore does not self-evidently qualify as 
commonly agreed fact. It might well be true for /some/ apps, especially 
if they are saved and then restored on exactly the same host from the 
same parent process with little or no intervening change to the 
underlying operating and process system environment (and ignoring any 
effect the pause might have on timings). However, even in those limited, 
albeit rather vaguely defined, circumstances I don't think we can 
presume it will be true for all apps.

It's worse than that though. For the primary use case I think you are 
talking about -- running services in a container on cloud infrastructure 
-- I think it is quite possible that a deployment may fail even to meet 
those rather vaguely set out requirements.   Might a saved app state not 
be resumed many times, possibly concurrently? Might local OS resources 
conceivably change between restarts? Might the parent process env 
conceivably change between restarts? Indeed, might those effects not 
actually occur because of the very fact that the app is being restarted?

Unfortunately, the current operation of the JVM and JDK implicitly 
presumes a high degree of continuity in the process and OS env during 
execution. It has most definitely not been made 100% resilient to any 
sudden discontinuity from one point of execution to the next thanks to 
whatever change might happen in some intervening hiatus caused by a save 
and subsequent restore.

We could ignore that problem on the grounds that it is not a goal of the 
project to consider it and claim, in consequence, that anyone running 
into problems because of it has to look out for themselves. However, in 
doing so I believe we would run the risk of significantly lowering the 
value of whatever the project might come up with.

The alternative is to plan for and spend effort looking through the JDK 
runtime and JVM code to identify where it needs to be made resilient to 
save and restore and provide means for any potential disruption that it 
might cause to be detected and either repaired or, at least, managed 
with a graceful failure. I believe very firmly that this latter course 
is the one we should follow.


Andrew Dinn

More information about the discuss mailing list