Call for Discussion: New Project: CRaC

[Anton Kozlov]

Hi Andrew,

This is a very interesting topic.  The targeted problems are similar, but the
means and implications are different.  There may be few intersections.
However, I'm not sure how practical they are.

Taking this another way, to reduce the start-up of the static Java program, as
much as possible of execution is performed in the compile time.  From GraalVM,
sometimes you need human assistance or a profiling run that provides missing
pieces of information.  The warm-up is solved by analyzing and optimizing all
the future execution paths.

A run with CRaC API could be a profiling phase that constructs 100% of the
state without a complex analysis of the initialization phase.  We don't need an
analysis if we have a complete result of a single run.  Even if it caught too
many details of that run, a java program can register beforeCheckpoint callback
to clear some parts of the state before it is saved.  For example, it could be
possible to dump java heap, metaspace, etc at the time of "checkpoint", while
the result is not a real runtime image.  And then use this JVM data as a
starting point for the static Java program compilation, compiling in
afterRestore methods that update the state after the restore in CRaC.  In
theory, any choice that cannot be decided by static analysis from the initial
run could even be treated as unreachable.  So the amount of information for
static analysis and the outcome of compilation will be regulated by the
extensiveness of the profiling run.

And still, the same Java code with CRaC API could be used saved as a part of a
complete Java runtime image, done by VM, CRIU, etc.

Thanks,
Anton


On 7/21/21 12:26 PM, Andrew Dinn wrote:
> 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
> -----------
>