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

[Staffan Larsen]

Thanks Serguei.

The comments were copied from the solaris code, but I agree that they could be cleaned up.

/Staffan

On 14 apr 2014, at 20:38, serguei.spitsyn at oracle.com wrote:

> 
> src/os/bsd/vm/os_bsd.cpp
> 
>  In the comments at 1032-1043:
> 
>  1. Would it be better to consistently name vars as obsv/prev, not obs/prv ?
>     I had no problem to understand comments however my mind tries to associate 'obs' with 'obsolete'.
> 
>  2. The link http://blogs.sun.com/dave/entry/cas_and_cache_trivia_invalidate
>     is resolved to https://blogs.oracle.com/ which is not very useful.
> 
> 
> 
> Thanks,
> Serguei
> 
> 
> On 4/14/14 7:55 AM, Staffan Larsen wrote:
>> The current implementation of System.nanoTime() on OS X uses gettimeofday() which has only microsecond precision and no guarantees on being monotonic.
>> 
>> 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.
>> 
>> This change also adds support for AssumeMonotonicOSTimers to the solaris code (see JDK-6864866) and removes the use of Atmoic::load() for a 64-bit value which was necessary on 32-bit platforms (which we don’t support any longer).
>> 
>> This change has been proposed earlier at: http://mail.openjdk.java.net/pipermail/hotspot-dev/2013-May/009496.html
>> 
>> webrev: http://cr.openjdk.java.net/~sla/8040140/webrev.00/
>> bug: https://bugs.openjdk.java.net/browse/JDK-8040140
>> 
>> Thanks,
>> /Staffan
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20140415/8a372c40/attachment-0001.html>