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.fu...@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
