Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8246112

Remove build-time and run-time checks for clock_gettime and CLOCK_MONOTONIC



    • b07


      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:


      # 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"

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


        Issue Links



              dholmes David Holmes
              dholmes David Holmes
              0 Vote for this issue
              5 Start watching this issue