<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Here is an updated webrev with changes to the comments in os_bsd.cpp and os_solaris.cpp.<div> - obs -> obsv</div><div> - fixed URL to blog entry</div><div><br></div><div><a href="http://cr.openjdk.java.net/~sla/8040140/webrev.01/">http://cr.openjdk.java.net/~sla/8040140/webrev.01/</a></div><div><br></div><div>/Staffan</div><div><div><br><div><div>On 15 apr 2014, at 07:52, Staffan Larsen <<a href="mailto:staffan.larsen@oracle.com">staffan.larsen@oracle.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="font-size: 16px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br>On 14 apr 2014, at 21:08, Aleksey Shipilev <<a href="mailto:aleksey.shipilev@oracle.com">aleksey.shipilev@oracle.com</a>> wrote:<br><br><blockquote type="cite">On 04/14/2014 06:55 PM, Staffan Larsen wrote:<br><blockquote type="cite">mach_absolute_time() is essentially a direct call to RDTSC, but with<br>conversion factor to offset for any system sleeps and frequency<br>changes. The call returns something that can be converted to<br>nanoseconds using information from mach_timebase_info(). Calls to<br>mach_absolute_time() do not enter the kernel and are very fast. The<br>resulting time has nanosecond precision and as good accuracy as one<br>can get.<br></blockquote><br>Some numbers would be good on the public list :) I know the numbers<br>already, but others on this list don’t.<br></blockquote><br>I posted the numbers in the bug, but forgot to say so here...<br><br><blockquote type="cite"><br><blockquote type="cite">Since the value from RDTSC can be subject to drifting between CPUs,<br>we implement safeguards for this to make sure we never return a lower<br>value than the previous values. This adds some overhead to nanoTime()<br>but guards us against possible bugs in the OS. For users who are<br>willing to trust the OS and need the fastest possible calls to<br>System.nanoTime(), we add a flag to disable this safeguard:<br>-XX:+AssumeMonotonicOSTimers.<br></blockquote><br>I now wonder if this safeguard can produce a stream of exactly the same<br>timestamps if local clock is lagging behind. But considering the<br>alternative of answering the retrograde time, and the observation the<br>current Mac OS X mach_absolute_time() *appears* monotonic, having this<br>safeguard seems OK.<br><br><blockquote type="cite">webrev: <a href="http://cr.openjdk.java.net/~sla/8040140/webrev.00/">http://cr.openjdk.java.net/~sla/8040140/webrev.00/</a><br>bug: <a href="https://bugs.openjdk.java.net/browse/JDK-8040140">https://bugs.openjdk.java.net/browse/JDK-8040140</a><br></blockquote><br>This looks good to me.<br></blockquote><br>Thanks.<br><br><blockquote type="cite">And, since this question will inevitably pop up, do we plan to bring it<br>into 8uX? I think many Mac users will be happy about that.<br></blockquote><br>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?<br><br>/Staffan</div></blockquote></div><br></div></div></body></html>