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

[Aleksey Shipilev]

On 04/14/2014 06:55 PM, Staffan Larsen wrote:
> 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.

Some numbers would be good on the public list :) I know the numbers
already, but others on this list don't.

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

I now wonder if this safeguard can produce a stream of exactly the same
timestamps if local clock is lagging behind. But considering the
alternative of answering the retrograde time, and the observation the
current Mac OS X mach_absolute_time() *appears* monotonic, having this
safeguard seems OK.

> webrev: http://cr.openjdk.java.net/~sla/8040140/webrev.00/
> bug: https://bugs.openjdk.java.net/browse/JDK-8040140

This looks good to me.

And, since this question will inevitably pop up, do we plan to bring it
into 8uX? I think many Mac users will be happy about that.

Thanks,
-Aleksey.