JDK-8246112 : Remove build-time and run-time checks for clock_gettime and CLOCK_MONOTONIC
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 17
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2020-05-29
  • Updated: 2021-04-15
  • Resolved: 2021-01-27
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 17
17 b07Fixed
Related Reports
Relates :  
Relates :  
Relates :  
We are reaching a point where our oldest supported Linux systems (and other POSIX compliant OS) have guaranteed support for clock_gettime and CLOCK_MONOTONIC, and without the need to link librt.so on Linux. All the code we have in relation to SUPPORTS_CLOCK_MONOTONIC can be unconditionalized.

There was further discussion in this thread:



The "clock_gettime(3) - Linux man page" says: "All implementations
support the system-wide realtime clock, which is identified by
CLOCK_REALTIME. Its time represents seconds and nanoseconds since the Epoch.". See: https://linux.die.net/man/3/clock_gettime

FYI Some older Linux ports used to implement
clock_gettime(CLOCK_REALTIME,) by calling gettimeofday() and
multiplying by 1000. This would be fine with the patch proposed, but
means that resolution would be limited to microseconds by the OS. A
Linux change 6 months ago has discouraged that in ports: "Use
clock_gettime to implement gettimeofday"

and here:


clock_gettime was already in Linux 2.6.12 (and possibly quite a bit
earlier, I did not check), so that is not likely to be a limitation.

A tricky question is whether it's possible to avoid loading librt.
The present code already uses dlopen, but I think it could try a
little bit harder (try resolving clock_gettime first, and then load
librt, and try again).  For distribution builds that do not need to be
compatible with glibc versions before 2.17, directly calling
clock_gettime would also be an option. (clock_gettime moved to
libc.so.6 in glibc 2.17, but a lot of software keeps linking against
librt for the definition of clock_gettime, something that we are
finally tackling on the glibc side.)
Changeset: 6f2be9c6 Author: David Holmes <dholmes@openjdk.org> Date: 2021-01-27 01:18:52 +0000 URL: https://git.openjdk.java.net/jdk/commit/6f2be9c6

Oh, this fell through the cracks, sorry. I'll schedule time next week.

[~stuefe] are you able to follow up on this one now? Thanks.

I encountered a problem moving ahead with this due to a current constraint on our Oracle JDK builds to support building in an environment that only has glibc 2.12. While looking into the possibility of using a later build environment, but still remain 2.12 compatible, I realized that our use of dynamic runtime linking to handle platforms with zero clock_* support, was actually obscuring the fact that as long as we link with librt, then we can assume existence of clock_* functions at build-time and run-time! In short we could have fixed this many years/releases ago. So unless there is some consequence of explicitly/unconditionally linking librt that I am unaware of, that is what I will do.

[~stuefe] No rush I'm on vacation too :)

Sorry, I'm on vacation. Can you please ask on aix-dev (or one of the other guys directly)?

OpenBSD 3.4 is the first release to support CLOCK_MONOTONIC - that was in November 2003 FreeBSD 3.0 is the first release to support CLOCK_MONOTONIC - that was in October 1998 NetBSD has an unclear history, but we have support at least as late as NetBSD 7 in 1999.

[~stuefe] can you confirm that this is okay for the AIX port? (That we can assume build-time and runtime support for clock_gettime(CLOCK_MONOTONIC)). Thanks.

Targeting to 17 as I think another 12 months should allow minimum supported platform levels to move into even safer territory.