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

Staffan Larsen staffan.larsen at oracle.com
Tue Apr 15 05:52:18 UTC 2014

On 14 apr 2014, at 21:08, Aleksey Shipilev <aleksey.shipilev at oracle.com> 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.

I posted the numbers in the bug, but forgot to say so here...

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

I would like to do so, but I would also like to have it sit and bake for a while in 9 before that. I think the 8u20 train has left the station, but perhaps 8u40?


More information about the hotspot-runtime-dev mailing list