Portability of checkpoints?

[Ashutosh Mehra]

Hi,

We are doing some experiments to understand the impact of change in the
environment
(could be anything like cpu features, number of cpus, cache line size etc)
on the functionality
of the JVM after it restores from a checkpoint.

It is a work in progress and while we continue our investigation, I thought
it would be good
to document and summarize our findings so far.
I have done a write-up [1] describing the problems we faced and our
observations.

1. Between machines with the same operating system distribution.  The CPU
> features set is a good example of this.  Also, available memory resources can
> change between checkpoint and restore.  We'll likely need to change JVM to
> handle the difference.  Here we have containers -- it's interesting that even
> when starting on the same physical machine (same CPU), a container instance
> used for the checkpoint and a container for the restore may have different
> hard memory limits.
>
>
We are currently looking at this configuration.The write-up focuses on the
effects of change in cpu features.

Couple of things that stand out:
1. Portability of a checkpoint is not just a JVM problem. The problems that
JVM faces may apply
to native libraries as well. If that happens a coordinated effort would be
needed from all the parties involved.
2. Need for an option that would allow Hotspot to generate portable code at
runtime.

Feel free to provide feedback/suggestions.

[1] http://cr.openjdk.java.net/~heidinga/crac/Portability_of_checkpoints.pdf

Thanks,
Ashutosh Mehra