[crac] RFR: Portable C/R [v2]

Radim Vansa rvansa at openjdk.org
Fri Jun 7 11:21:47 UTC 2024


On Tue, 4 Jun 2024 17:20:59 GMT, Timofei Pushkin <duke at openjdk.org> wrote:

>> Implements a proof-of-concept "portable mode" for CRaC: a checkpoint-restore mechanism that does not rely on platform-dependent tools like CRIU instead saving VM state in terms of the Java specification (with some HotSpot specifics) — this allows to restore the saved state on machines with different CPU architecture and OS. A demo is available [here](https://github.com/TimPushkin/portable-crac-demo).
>> 
>> Expected downsides compared to the traditional CRaC are restrictions on platform-dependent code usage (e.g. at the moment of checkpoint no native methods can be executing, off-heap memory obtained via `sun.misc.Unsafe` should be released) and somewhat slower restoration speeds (because platform-dependent state, including JIT-compiled code, should be re-created). In the future, Project Leyden may help with the latter.
>> 
>> The mechanism is implemented as an internal part of HotSpot, it gets activated when an empty `CREngine` VM option is passed (i.e. `-XX:CREngine=""`, this is a temporary solution). Main implementation details are described in [this doc](https://github.com/TimPushkin/crac/blob/portable-cr/trimmed/doc/portable-cr.md).
>> 
>> Since this is a proof-of-concept implementation, it currently lacks some important features. E.g. at the moment some early-initialized classes are not restored, most of JDK classes have not yet been properly adapted, checkpointing via `jcmd` is not fully supported, additional tests and optimizations are needed.
>
> Timofei Pushkin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update full name

Thanks you for the answers so far. If the PR is not yet ready for integration, would you mind marking it as 'Draft'? I think that such significant addition (resulting in some maintenance costs) would need a broader acceptance; probably worth introducing your ideas on the [crac-dev mailing list](https://mail.openjdk.org/mailman/listinfo/crac-dev).

I am curious about the problems you experience with Springboot - what aspects get harder to handle with your approach?

-------------

PR Comment: https://git.openjdk.org/crac/pull/155#issuecomment-2154630267


More information about the crac-dev mailing list