os::javaTimeSystemUTC to call nanosecond precision OS API, so Clock.systemUTC() can give nanosecond precision UTC

[Mark Kralj-Taylor]

David, Daniel,
What is the oldest (lowest) version of Linux and glibc for openjdk 15?

The availability of clock_gettime(CLOCK_REALTIME) on the oldest
Linux/glibc supported by openjdk 15 is likely to be the deciding
factor on if Hotspot Linux code can call
clock_gettime(CLOCK_REALTIME).

doc/building.md suggests minimum Linux is Oracle Enterprise Linux 6.4
(i.e. RHEL 6.4).
Which I think uses glibc 2.12-1.107 (based on
https://yum.oracle.com/repo/OracleLinux/OL6/4/base/x86_64/index_src.html).
Searching for glibc sources it looks like this supports
clock_gettime(CLOCK_REALTIME).

The wording of Linux docs suggests that clock_gettime(CLOCK_REALTIME)
should be supported if the clock_gettime() API exists. But other clock
sources are not mandatory. So CLOCK_REALTIME should be available even
if CLOCK_MONOTONIC is not.
- See: https://linux.die.net/man/2/clock_gettime.
- Also "POSIX.1-2008 marks gettimeofday() as obsolete, recommending
the use of clock_gettime(2) instead." from:
https://linux.die.net/man/2/gettimeofday

Note that Hotspot os_posix.cpp checks for non-error return from
clock_gettime(CLOCK_MONOTONIC) to guard setting the _clock_gettime
function pointer. Which was why in the patch I called clock_gettime
directly for Linux specific os_linux.cpp (a subset of Posix OS-s).

Also os_linux.cpp has:
#ifndef SUPPORTS_CLOCK_MONOTONIC
#error "Build platform doesn't support clock_gettime and related functionality"
#endif
Which made me wonder if openjdk might require CLOCK_MONOTONIC - which
would mean clock_gettime(CLOCK_REALTIME) is supported.

Mark

On Tue, 14 Apr 2020 at 18:04, Mark Kralj-Taylor <kralj.mark at gmail.com> wrote:
>
> Daniel,
> Yes System.currentTimeMillis() and Clock.systemUTC() must be
> consistent, so should use the same OS time source (as shown by ).
>
> The patch to os_linux.cpp ensures this by calling the same Linux API:
> clock_gettime(CLOCK_REALTIME) for both, from:
> - os::javaTimeMillis() that backs System.currentTimeMillis()
> - os::javaTimeSystemUTC() that backs Clock.systemUTC()
>
> Looking at Linux / glibc source I think that gettimeofday() and
> clock_gettime(CLOCK_REALTIME) are supposed to be the same clocksource.
> i.e. that given by: cat
> /sys/devices/system/clocksource/clocksource0/current_clocksource
>
> Mark
>
> On Tue, 14 Apr 2020 at 13:29, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
> >
> > Hi,
> >
> > On 11/04/2020 00:53, David Holmes wrote:
> > > Update:
> > >> It's a holiday weekend so I can't dig into this right now but we tried
> > >> using a high-precision clock source for systemUTC() in the past but it
> > >> didn't work because systemUTC() and currentTimeMillis() have to use
> > >> the same time base, and currentTimeMillis() has to use gettimeofday().
> > >> I thought this cross-dependency was documented somewhere but can't
> > >> find it right now. If gettimeofday and clock_gettime(CLOCK_REALTIME)
> > >> actually have the same time characteristics wrt. wall-clock time then
> > >> changing both as suggested may indeed work.
> >
> > Just to emphasize David's comment: System::currentTimeMillis() and
> > Clock::systemUTC() should use the same time source: if they don't - then
> > some tests will fail, and because it can be tricky to assert things
> > in tests, they might (and probably will) fail only intermittently.
> >
> > I'm probably the culprit here, I added those tests when I upgraded
> > Clock::systemUTC() to report sub millisecond granularity [1] - as was
> > available in the underlying clock that System::currentTimeMillis()
> > already used.
> >
> > However, I think I would be disturbed if System::currentTimeMillis()
> > and Clock::systemUTC() were using different clocks and could
> > report a different notion of time (by drifting away from each other).
> >
> > best regards,
> >
> > -- daniel
> > [1] https://bugs.openjdk.java.net/browse/JDK-8068730