Bug ID: JDK-8246112 Remove build-time and run-time checks for clock_gettime and CLOCK

Versions (Unresolved/Resolved/Fixed)

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

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:

https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-April/038975.html

# IS THIS A SAFE CHANGE for Linux?

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"
https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=5e46749c64d51f50f8511ed99c1266d7c13e182b.

and here:

https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-April/039009.html

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
27-01-2021
Oh, this fell through the cracks, sorry. I'll schedule time next week.
22-01-2021
[~stuefe] are you able to follow up on this one now? Thanks.
21-01-2021
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.
14-01-2021
[~stuefe] No rush I'm on vacation too :)
19-12-2020
Sorry, I'm on vacation. Can you please ask on aix-dev (or one of the other guys directly)?
19-12-2020
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.
19-12-2020
[~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.
19-12-2020
Targeting to 17 as I think another 12 months should allow minimum supported platform levels to move into even safer territory.
29-05-2020

Relates :	JDK-8242504 - Enhance the system clock to nanosecond precision
Relates :	JDK-8262501 - jdk17 libjvm link failure with --as-needed and clock_gettime in librt
Relates :	JDK-8258917 - NativeMemoryTracking is handled by launcher inconsistenly