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.)