It is expected for apps to temporarily change their otherwise stable state during checkpoint-restore, for example close a previously always-open file descriptor on checkpoint and reopen it after restore. This may trigger deoptimization and decompilation (nmethods becoming not entrant) of code depending on that state. After restore that code will likely undergo the full profiling cycle which may take some time and thus constitute an after-restore warmup.

We can reduce the length of this warmup by artificially triggering recompilation of methods decompiled during and shortly after C/R. We assume that by the time we trigger recompilation the app's state becomes stable again and is quite similar to the one that existed before the checkpoint.