[crac] RFR: Correct System.nanotime() value after restore [v2]
Radim Vansa
duke at openjdk.org
Fri May 12 07:30:08 UTC 2023
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 After trying to run C/R with fewer privileges in containers I am starting to see the value of moving away from CRIU; it does more than JVM usually needs, but this requires elevated privileges. Leaving it all at once would be a tremendous endeavour, though, so slowly dropping functionality, even through adding some switches into CRaC fork to disable some parts makes sense to me.
-------------
PR Comment: https://git.openjdk.org/crac/pull/53#issuecomment-1545300602
More information about the crac-dev
mailing list