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

Radim Vansa duke at openjdk.org
Thu Mar 30 14:36:59 UTC 2023


On Tue, 28 Mar 2023 10:12:34 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 2051:
> 
>> 2049:     diff_millis = 0;
>> 2050:   }
>> 2051:   javaTimeNanos_offset = checkpoint_nanos - javaTimeNanos() + diff_millis * 1000000L;
> 
> So all the difference in MONOTONIC clocks is eliminated and replaced with REALITIME estimation, even if the restore was performed on the same machine and the monotonic clocks difference made sense. That may invalidate some measurements done with System.nanoTime() around checkpoint-restore 
> 
> 
> long before = System.nanoTime();
> // ... checkpoint & restore .. 
> long after = System.nanoTime();
> System.out.println(after - before);
> 
> 
> One of the way to fix that is to fix just monotonicity of System.nanoTime(), preventing that going backward.
> 
> 
> long diff = javaTimeNanos() - checkpoint_nanos;
> if (diff < 0) {
>   javaTimeNanos_offset = -diff
> }
> 
> 
> But that anyway will fail if the timens has been changed (that we can probably detect) or when the image is transfered to another machine (that should be possible, but probably more tricky). Do we have any way to detect we've been transfered to another machine and report a warning in this case, with possible millis approximation enabled?

If the monotonic time on the machine advanced by X, the offset can't be lower than -X (as the millis part is always positive) and therefore any difference between times read before and after will be at least 0. Therefore things snapshot might seem to take no time, but System.nanoTime() is still monotonic.

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

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


More information about the crac-dev mailing list