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

[Mark Kralj-Taylor]

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