Portability of checkpoints?
Ashutosh Mehra
asmehra at redhat.com
Fri Feb 4 18:41:05 UTC 2022
For reference, the previous discussion on portability can be seen at:
https://mail.openjdk.java.net/pipermail/crac-dev/2021-October/000029.html
Thanks,
Ashutosh Mehra
On Fri, Feb 4, 2022 at 12:38 PM Ashutosh Mehra <asmehra at redhat.com> wrote:
> 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
>
More information about the crac-dev
mailing list