Call for Discussion: New Project: CRaC

[Andrew Dinn]

On 18/07/2021 15:48, Anton Kozlov wrote:
> 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.
This proposal rings bells with project Leyden. I'm not proposing the 
need for any absolute tie between the two projects but I just want to 
note that Leyden faces some similar concerns and that an integrated 
approach to resolving them might be beneficial.

With static Java programs much of the fast startup and low footprint 
comes from having a pre-populated heap that contains primitive data and 
objects created by running static initialization during generation of 
the static image. This is somewhat dissimilar to CRAC in that the 
initial heap is not really a snapshot of a prior heap state. Instead it 
is an explicitly constructed initial data state for operation of the 
static compiled program. That includes linking it to an associated, 
complete and closed meta-data model. Despite that difference similar 
concerns arise.

Experience from GraalVM indicates that not all heap data can be fully 
constructed in advance to cater for all possible variations in the 
target platform. This suggests that it would be beneficial to provide 
some language or runtime mechanism to 'complete' or 'repair' the initial 
heap state at startup. If we can see some way to align the needs of 
these two projects then we might be able to align any language or 
runtime capabilities support required to resolve those needs.

regards,


Andrew Dinn
-----------