[crac] RFR: Correct System.nanotime() value after restore [v7]

Radim Vansa duke at openjdk.org
Fri May 12 08:46:14 UTC 2023


On Fri, 12 May 2023 05:49:28 GMT, Radim Vansa <duke at openjdk.org> wrote:

>> There are various places both inside JDK and in libraries that rely on monotonicity of `System.nanotime()`. When the process is restored on a different machine the value will likely differ as the implementation provides time since machine boot. This PR records wall clock time before checkpoint and after restore and tries to adjust the value provided by nanotime() to reasonably correct value.
>
> Radim Vansa has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:
> 
>  - Merge branch 'crac' into nanotime
>  - Fix whitespaces
>  - Use image under ghcr.io/crac
>  - Ensure monotonicity for the same boot
>  - Set nanotime only if bootid changes
>  - Reset nanotime offset before calculating it again
>  - Correct time since restore
>  - Merge remote-tracking branch 'origin/crac' into nanotime
>  - Adjust System.nanoTime() to keep consistent time origin after restore
>  - Merge remote-tracking branch 'origin/crac' into test-crac-java
>  - ... and 8 more: https://git.openjdk.org/crac/compare/ef2437e7...87d19a12

Actually thanks to rebooting I was able to run into the issue CI encountered - using negative monotonic offset could end up setting the time to negative value. I've fixed this by shifting the monotonic offset for the checkpoint rather than for restore in this case.

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

PR Comment: https://git.openjdk.org/crac/pull/53#issuecomment-1545391284


More information about the crac-dev mailing list