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

[Radim Vansa]

On Thu, 30 Mar 2023 14:17:01 GMT, Radim Vansa <duke at openjdk.org> wrote:

>> src/hotspot/share/runtime/os.cpp line 2041:
>> 
>>> 2039:       checkpoint_millis = javaTimeMillis();
>>> 2040:       checkpoint_nanos = javaTimeNanos();
>>> 2041:   }
>> 
>> Sorry, I don't follow why for repeated checkpoint-restore it's enough or desireable to store checkpoint_nanos once. Suppose we've done first restore on the same machine that was used for checkpoint (roughly millis diff equals to nanos diff, so time adjustement implemented does not contritube anything for first restore), then checkpoint again. And then perform 2nd restore on another machine in a very short time, suppose immediatelly. Then `checkpoint_nanos - javaTimeNanos()` adjustement can become any value, depending on the difference between clocks on two machines, completely unrelated to each other.
>
> It estabilishes relation between real time and monotonic time, and it's sufficient to do that just once
> 
> // 1st checkpoint
> checkpoint_millis = 1
> checkpoint_nanos = 1_000_000
> // almost immediate restore
> javaTimeMillis() -> 2
> monotonic nanos -> 2_000_000
> diff_millis = 1
> javaTimeNanos_offset = 0
> // second checkpoint does not record anything
> // 2nd restore
> javaTimeMills() -> 3
> monotonic nanos -> 100_000_000
> diff_millis = 2
> javaTimeNanos_offset = 1_000_000 - 100_000_000 + 2 * 1_000_000 = -97_000_000
> javaTimeNanos() -> system monotonic nanos + offset = 3_000_000
> 
> In the last step we've read a value that makes sense to compare to any nanoTime in any previous phase.

Oh wait a sec, you're partially right - since we always use javaTimeNanos() if the offset calculated after the first restore wouldn't be zero, we wouldn't have this right. I should zero the offset before calculating it again. Too bad I can't create a test for that yet.

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

PR Review Comment: https://git.openjdk.org/crac/pull/53#discussion_r1153348585