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

[serguei.spitsyn at oracle.com]

Somehow the 'obs', 'prv' and the old link are still in new webrev:

1033     // If the CAS failed and the observed value "obs" is >= now then
1034     // we should return "obs".  If the CAS failed and now > obs > prv then
1037     // or (c) just return obs.  We use (c).   No loop is required although in some cases
1041     // We might also condition (c) on the magnitude of the delta between obs and now.

1043     // See http://blogs.sun.com/dave/entry/cas_and_cache_trivia_invalidate

But I believe, you really fixed it in the repo. :)

Thanks,
Serguei

On 4/14/14 11:00 PM, Staffan Larsen wrote:
> Here is an updated webrev with changes to the comments in os_bsd.cpp 
> and os_solaris.cpp.
>  - obs -> obsv
>  - fixed URL to blog entry
>
> http://cr.openjdk.java.net/~sla/8040140/webrev.01/ 
> <http://cr.openjdk.java.net/%7Esla/8040140/webrev.01/>
>
> /Staffan
>
> On 15 apr 2014, at 07:52, Staffan Larsen <staffan.larsen at oracle.com 
> <mailto:staffan.larsen at oracle.com>> wrote:
>
>>
>> On 14 apr 2014, at 21:08, Aleksey Shipilev 
>> <aleksey.shipilev at oracle.com <mailto: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/ 
>>>> <http://cr.openjdk.java.net/%7Esla/8040140/webrev.00/>
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8040140
>>>
>>> This looks good to me.
>>
>> Thanks.
>>
>>> 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?
>>
>> /Staffan
>

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