Call for Discussion: New Project: CRaC

[Andrew Dinn]

Hi Anton,

On 21/07/2021 13:11, Anton Kozlov wrote:
> 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.

Me neither, but I still think it would be well worth considering if 
there are any commonalities.

> 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.

Well, that's how it works at present given the current language spec and 
behaviour of the JVM, runtime, middleware and apps that are all designed 
with the expectation of operating in a single continuous dynamic 
runtime. But the it does not necessarily have to remain that way.

One option for Java that would accommodate the static case might be to 
factor out static state initialization into computation of state that it 
is acceptable to precompute vs state that needs either to be initialized 
because it was not precomputed or, if it was already precomputed, 
re-initialized at runtime. There is also the opportunity to determine 
when it gets re-initialized -- e.g. before the program starts running or 
at the point where the program needs to make use of it.

It would be interesting to consider how a restart of a frozen JVM state 
might also profit from a similar mechanism. There is clearly the 
potential to recompute existing (static) class state when an app is 
restarted, just as with a static app startup. However, there may also be 
a need to refresh instance state.

> 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.

Well, yes, currently build time init requires a complex analysis of 
static init code. However, you would not necessarily need to have a 
static analysis if the language, runtime, middleware and apps were 
provided with a mechanism to define what can be pre-computed vs runtime 
computed vs re-computed. It seems clear that for some apps it will be 
easy for them to correct their own internal app state using callbacks. 
However, it is not clear that JDK runtime state or JVM state will always 
be correct at restart of a frozen app. Certainly not if you transplant 
the app to a host with a different hardware, OS or process environment.

So, I think there is a need to look into how we can make the JDK and JVM 
play ball here and preferably in much the same way as we need to look at 
making it play ball with a static compile model.

regards,


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