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

[Ashutosh Mehra]

On Thu, 23 Mar 2023 15:38:35 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.

I understand this change is trying to adjust the return value of any calls made to System.nanoTime() after restore to take into account the elapsed time between checkpoint and restore.
In principle this idea is very similar to CLOCK_BOOTTIME [0] which takes into account the time system has spent in suspend state.
I came across an issue [1] in golang which was suggested to replace CLOCK_MONOTONIC with CLOCK_BOOTTIME but it was considered ill-advised and was closed. There was even a linux kernel patch [2] to make CLOCK_MONOTONIC behave as CLOCK_BOOTTIME which was reverted [3] immediately because it broke many of the existing userland softwares.
Considering this precedent, I think we should also consider the impact of this change on existing frameworks and libraries, that is, can this change break the existing code patterns that use System.nanoTime()?

[0] https://man7.org/linux/man-pages/man3/clock_gettime.3.html
[1] https://github.com/golang/go/issues/24595
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d6ed449afdb38f89a7b38ec50e367559e1b8f71f
[3] https://www.spinics.net/lists/linux-tip-commits/msg43709.html

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

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