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