[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