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

System.nanoTime() is slow and non-monotonic on OS X

    Details

    • Type: Bug
    • Status: Closed
    • Priority: P2
    • Resolution: Fixed
    • Affects Version/s: 7u80, 9
    • Fix Version/s: 9
    • Component/s: hotspot
    • Subcomponent:
    • Resolved In Build:
      b13
    • OS:
      os_x
    • Verification:
      Not verified

      Backports

        Description

        The current implementation of System.nanoTime() on OS X uses gettimeofday() which has only microsecond precision and no guarantees on being monotonic.

          Issue Links

            Activity

            Hide
            sla Staffan Larsen (Inactive) added a comment -
            The proposal is to use the system call mach_absolute_time() instead of gettimeofday() and to add safeguard to guarantee that the time is monotonic (similar to what we already have on solaris).

            mach_absolute_time() is essentially a direct call to RDTSC, but with conversion factor to offset for any system sleeps and frequency changes. The call returns something that can be converted to nanoseconds using information from mach_timebase_info(). Calls to mach_absolute_time() do not enter the kernel and are very fast. The resulting time has nanosecond precision and as good accuracy as one can get.

            Since the value from RDTSC can be subject to drifting between CPUs, we implement safeguards for this to make sure we never return a lower value than the previous values. This adds some overhead to nanoTime() but guards us against possible bugs in the OS. For users who are willing to trust the OS and need the fastest possible calls to System.nanoTime(), we add a flag to disable this safeguard: -XX:+AssumeMonotonicOSTimers (see JDK-6864866).
            Show
            sla Staffan Larsen (Inactive) added a comment - The proposal is to use the system call mach_absolute_time() instead of gettimeofday() and to add safeguard to guarantee that the time is monotonic (similar to what we already have on solaris). mach_absolute_time() is essentially a direct call to RDTSC, but with conversion factor to offset for any system sleeps and frequency changes. The call returns something that can be converted to nanoseconds using information from mach_timebase_info(). Calls to mach_absolute_time() do not enter the kernel and are very fast. The resulting time has nanosecond precision and as good accuracy as one can get. Since the value from RDTSC can be subject to drifting between CPUs, we implement safeguards for this to make sure we never return a lower value than the previous values. This adds some overhead to nanoTime() but guards us against possible bugs in the OS. For users who are willing to trust the OS and need the fastest possible calls to System.nanoTime(), we add a flag to disable this safeguard: -XX:+AssumeMonotonicOSTimers (see JDK-6864866 ).
            Hide
            sla Staffan Larsen (Inactive) added a comment -
            Results from the org.openjdk.jmh.benchmarks.NanoTimerBench (http://hg.openjdk.java.net/code-tools/jmh/file/57623b7f64e6/jmh-core-benchmarks/src/main/java/org/openjdk/jmh/benchmarks/NanoTimerBench.java) JMH benchmark:


            gettimeofday() one thread (-wi 1 -f 0 -t 1)

            Benchmark Mode Samples Mean Mean error Units
            o.o.j.b.NanoTimerBench.granularity avgt 5 1045.209 14.944 ns/op
            o.o.j.b.NanoTimerBench.latency avgt 5 48.219 1.234 ns/op


            mach_absolute_time() with monotonic guarantee, one thread (-wi 1 -f 0 -t 1)

            Benchmark Mode Samples Mean Mean error Units
            o.o.j.b.NanoTimerBench.granularity avgt 5 41.527 3.871 ns/op
            o.o.j.b.NanoTimerBench.latency avgt 5 40.995 2.578 ns/op



            gettimeofday() five threads (-wi 1 -f 0 -t 5)

            Benchmark Mode Samples Mean Mean error Units
            o.o.j.b.NanoTimerBench.latency avgt 5 76.166 20.690 ns/op


            mach_absolute_time() with monotonic guarantee, five threads (-wi 1 -f 0 -t 5)

            Benchmark Mode Samples Mean Mean error Units
            o.o.j.b.NanoTimerBench.latency avgt 5 156.376 21.081 ns/op
            Show
            sla Staffan Larsen (Inactive) added a comment - Results from the org.openjdk.jmh.benchmarks.NanoTimerBench ( http://hg.openjdk.java.net/code-tools/jmh/file/57623b7f64e6/jmh-core-benchmarks/src/main/java/org/openjdk/jmh/benchmarks/NanoTimerBench.java ) JMH benchmark: gettimeofday() one thread (-wi 1 -f 0 -t 1) Benchmark Mode Samples Mean Mean error Units o.o.j.b.NanoTimerBench.granularity avgt 5 1045.209 14.944 ns/op o.o.j.b.NanoTimerBench.latency avgt 5 48.219 1.234 ns/op mach_absolute_time() with monotonic guarantee, one thread (-wi 1 -f 0 -t 1) Benchmark Mode Samples Mean Mean error Units o.o.j.b.NanoTimerBench.granularity avgt 5 41.527 3.871 ns/op o.o.j.b.NanoTimerBench.latency avgt 5 40.995 2.578 ns/op gettimeofday() five threads (-wi 1 -f 0 -t 5) Benchmark Mode Samples Mean Mean error Units o.o.j.b.NanoTimerBench.latency avgt 5 76.166 20.690 ns/op mach_absolute_time() with monotonic guarantee, five threads (-wi 1 -f 0 -t 5) Benchmark Mode Samples Mean Mean error Units o.o.j.b.NanoTimerBench.latency avgt 5 156.376 21.081 ns/op
            Hide
            hgupdate HG Updates added a comment -
            URL: http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/d11386591874
            User: sla
            Date: 2014-04-25 06:25:08 +0000
            Show
            hgupdate HG Updates added a comment - URL: http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/d11386591874 User: sla Date: 2014-04-25 06:25:08 +0000
            Hide
            hgupdate HG Updates added a comment -
            URL: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/d11386591874
            User: lana
            Date: 2014-05-14 17:13:22 +0000
            Show
            hgupdate HG Updates added a comment - URL: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/d11386591874 User: lana Date: 2014-05-14 17:13:22 +0000

              People

              • Assignee:
                sla Staffan Larsen (Inactive)
                Reporter:
                sla Staffan Larsen (Inactive)
              • Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: