[crac] RFR: Provide arguments for restore [v3]
Anton Kozlov
akozlov at openjdk.java.net
Sat Mar 5 07:58:30 UTC 2022
On Wed, 2 Mar 2022 18:53:41 GMT, Dan Heidinga <heidinga at openjdk.org> wrote:
>> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>>
>> Rename to newArguments, add javax.crac mirror
>
> src/hotspot/os/linux/os_linux.cpp line 5936:
>
>> 5934:
>> 5935: if (0 < info.si_int) {
>> 5936: *argp = get_new_args(info.si_int);
>
> Is `info.si_int` unique per restored process or will restoring the same image twice at the same time corrupt the shared memory?
>
> Basically, is the `inso.si_int` unique enough to be the id for the `/crac_%d` file?
Idea is exactly to avoid data corruption. For criu, it's a PID of the restoring process, that is, the PID that would java process receive with the usual start (without checkpoint/restore). The restoring process exists for the whole life of the restored java instance, so it is impossible for another restoring process to obtain the same ID.
For pauseengine, there is a slight change of ID reuse, as restoring process may exit earlier than the target VM pick up the data. But since chances are small, and pauseengine is mostly for debugging, I don't think it is a big problem. To mitigate, another ID generation scheme could be used, e.g. the ID could be the PID of the target VM.
-------------
PR: https://git.openjdk.java.net/crac/pull/16
More information about the crac-dev
mailing list