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

Radim Vansa duke at openjdk.org
Thu Mar 30 14:21:18 UTC 2023


On Tue, 28 Mar 2023 10:06:08 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Correct time since restore
>
> 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.

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

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


More information about the crac-dev mailing list