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

Anton Kozlov akozlov at openjdk.org
Fri Apr 21 15:19:19 UTC 2023


On Fri, 21 Apr 2023 15:00:47 GMT, Radim Vansa <duke at openjdk.org> wrote:

>> src/hotspot/os/linux/os_linux.cpp line 6605:
>> 
>>> 6603: 
>>> 6604: bool os::read_bootid(char *dest, size_t size) {
>>> 6605:   int fd = ::open("/proc/sys/kernel/random/boot_id", O_RDONLY);
>> 
>> Bood_id looks interesting! But AFAICS it remains the same for each new container, and the boot time may have been adjusted for that container.
>> 
>> anton at mercury:~$ docker run -it ubuntu:20.04 cat /proc/sys/kernel/random/boot_id
>> 9b913973-3082-471a-add5-6b802a04a9b2
>> anton at mercury:~$ docker run -it ubuntu:20.04 cat /proc/sys/kernel/random/boot_id
>> 9b913973-3082-471a-add5-6b802a04a9b2
>> anton at mercury:~$ cat /proc/sys/kernel/random/boot_id
>> 9b913973-3082-471a-add5-6b802a04a9b2
>> 
>> 
>> Should not we mix something extra to boot_id, for example, a hostname (which is different for each container)?
>
> The aim of this work is to prevent 'random' readings. New containers will keep the `boot_id` but their monotonic time *might* be adjusted, true. I agree with the comment above that in that case we should still ensure monotonicity, but since the readings are not 'random' I think that we can assume that the user did adjust monotonic time intentionally, and the application should observe that.

OK, agree. This may be a comment in the code, explaining that we leave some control of the time in the user's hands.

>> src/hotspot/share/runtime/os.cpp line 2055:
>> 
>>> 2053:     // Make the javaTimeNanos() on the next line return true monotonic time
>>> 2054:     javaTimeNanos_offset = 0;
>>> 2055:     javaTimeNanos_offset = checkpoint_nanos - javaTimeNanos() + diff_millis * 1000000L;
>> 
>> First assignment does not make effect.
>
> It does; `javaTimeNanos()` uses `javaTimeNanos_offset` underhood.

Indeed! Could you extend the comment, highlightint that javaTimeNanos uses javaTimeNanos_offset

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

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


More information about the crac-dev mailing list