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

[David Holmes]

On 15/04/2014 5:08 AM, Aleksey Shipilev wrote:
> 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.

Yes this can happen. Time "standing still" was deemed better than time 
going backwards (there have been a number of "bugs" filed when this is 
observed). Ultimately if the OS clock source is broken there is little 
the VM can do to make it right.

David

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