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

[Radim Vansa]

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

>> 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.

Fixed the problem above; I did a (unpublished) merge with #57 and wrote a test to validate the behaviour. Can contribute it after #57 gets merged (possibly in another PR).

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

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