Call for Discussion: New Project: CRaC
adinn at redhat.com
Wed Jul 21 13:27:56 UTC 2021
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
> sometimes you need human assistance or a profiling run that provides
> 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
> 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",
> 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
> 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.
More information about the discuss