[crac] RFR: Disable rseq in libc on checkpoint

[Volker Simonis]

On Tue, 11 Oct 2022 09:15:31 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

> Restartable sequences (rseq) [0] may be used by the glibc [1]. Without proper support of rseq in the ptrace [2], CRIU fails to create the checkpoint [3]. Some paravirtualized environments like Docker on Mac, and WSL, which are commonly used during development, still do not provide a proper rseq support, leading to the error. A simple usability workaround is to disable rseq in glibc. The patch disables rseq if JVM is started with -XX:CRaCheckpointTo and there is no explicit setting of rseq for glibc.  The workaround is not going to live forever, just until rseq support is implemented in the majority of environments. Alternatives like more clever detection of rseq in the ptrace, or detection of a paravirtualized environment seem too complex, having that positive impact from rseq on java performance is unknown. 
> 
> [0] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d7822b1e24f2
> [1] https://sourceware.org/git/?p=glibc.git;a=commit;h=95e114a0919d844d8fe07839cb6538b7f5ee920e. 
> [2] https://github.com/CRaC/criu/blob/cc01f191639a5c2c988f49f1e314d17b055497b2/criu/kerndat.c#L944
> [3] https://github.com/CRaC/criu/blob/cc01f191639a5c2c988f49f1e314d17b055497b2/criu/cr-dump.c#L225

This fix seems overly complicated and I don't like the fact that we exec in the launcher. This doesn't seem to be a very common use case so why do we not simply document it and instruct users who are affected to set the environment variable themselves? That looks like a pretty simple workaround to me.

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

PR: https://git.openjdk.org/crac/pull/31