[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