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

[Radim Vansa]

On Thu, 11 May 2023 14:39:21 GMT, Jan Kratochvil <duke at openjdk.org> wrote:

>>> Since you mention it was a bug in kernel or criu and it has been almost 3 years since your commit, may be it is worth enabling the criu changes again to see if the timedwait problem still exists, unless you have already done that.
>> 
>> AFAIK the bug is fixed, but I see no point of relying on OS here. Is there one? Timens that is not changed by CRIU provides correct values for our nanoTime() [1].
>> 
>>> The value returned represents nanoseconds since some fixed but arbitrary origin time (perhaps in the future, so values may be negative). The same origin is used by all invocations of this method in an instance of a Java virtual machine
>> 
>> [1] https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/System.html#nanoTime()
>
> Upstream criu does provide the time namespace as stated by @AntonKozlov:
> 
> CLOCK_MONOTONIC=301.735134591 CLOCK_BOOTTIME=301.735155494
> CLOCK_MONOTONIC=302.735345917 CLOCK_BOOTTIME=302.735358109
> Warn  (compel/arch/x86/src/lib/infect.c:356): Will restore 7757 with interrupted system call
> [1]+  Killed                  ./clock_gettime
> restore:
> CLOCK_MONOTONIC=302.803360137 CLOCK_BOOTTIME=302.803373299
> restore:
> CLOCK_MONOTONIC=302.806677876 CLOCK_BOOTTIME=302.806696098
> 
> I do not see why JVM should reimplement what CRIU already does. One can solve that in the future when CRaC is really going to run on non-Linux system. One will need to port or reimplement there CRIU in the first place.

@jankratochvil I have a fix for the sleepers in https://github.com/rvansa/crac/tree/timed_wait , will publish it as PR once this gets integrated.
Also, your trouble with libbsd should be resolved once https://github.com/CRaC/container-images/pull/4 gets integrated.

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

PR Comment: https://git.openjdk.org/crac/pull/53#issuecomment-1554361596