JDK-6864866 : add a flag to use result of gethrtime() directly in os::getTimeNanos() on Solaris and OS X
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: hs16
  • Priority: P3
  • Status: Closed
  • Resolution: Won't Fix
  • OS: os_x,solaris_10
  • CPU: generic
  • Submitted: 2009-07-24
  • Updated: 2022-05-06
  • Resolved: 2018-01-02
Related Reports
Relates :  
JDK-8040140 - System.nanoTime() is slow and non-monotonic on OS X
Relates :  
JDK-6863420 - os::javaTimeNanos() go backward on Solaris x86
Relates :  
JDK-6784100 - getTimeNanos - CAS reduction
Relates :  
JDK-6868976 - Sequester os_solaris.cpp'max_hrtime to its own cache line
Relates :  
JDK-6876279 - currentTimeMillis and nanoTime are too expensive
Description
###@###.### wrote:
 ...
> Given gethrtime is _supposed_ to be monotonic and that bugs whereby 
> it is not monotonic get addressed, and given this code is actually 
> performance sensitive - as the changes in 6784100 demonstrated - then 
> shouldn't we add a flag AlwaysdUseOSHighResTime so that we just use 
> gethrtime() directly? This flag could be used by people who care 
> about the performance and know enough about it to check that they 
> have the right patches for gethrtime() to be assumed to be working 
> correctly. Default value of the flag would be false of course  :)   

I did the experiment to return the result of gethrtime() without caching and got almost 6x improvement on x86!!!!!!

inline hrtime_t getTimeNanos() {
  if (VM_Version::supports_cx8()) {
    const hrtime_t now = gethrtime();
+ if (UseNewCode) return now;

I got ScaleHarness.java test from 6784100.

32-bit product VM System.nanoTime()
% gamma ScaleHarness -X 8 n

-XX:-UseNewCode
5614000 in 1010
5612000 in 1010
5613000 in 1010

-XX:+UseNewCode
31611000 in 1010
31606000 in 1010
31612000 in 1010
Comments
This is not on our list of current priorities. If there are additional specific customer requirements, we will consider reopening this issue. Closing as WNF.
02-01-2018
Closing bugs because they currently don't have resources to address them is incorrect - that may change in the future, if the bug is real closing it means that it will most likely *never* get fixed, even if resources subsequently become available.
30-03-2017
Not a priority, closing as WNF.
30-03-2017
As I said I think Solaris itself has been reliable for some time now. I'm okay to remove the workaround if we have confidence both raw OS and virtualized environment will work okay.
11-07-2016
On Solaris gethrtime() is guaranteed to be monotonic and there is code in the kernel to make sure that is the case, even when virtualised. The code currently in the JVM for Solaris is pointless and should simply be removed.
11-07-2016
gethrtime() has always been spec'd to be monotonic but we have found numerous cases where it was not - hence we had to add workarounds. When these issues are found bugs are filed against the OS as appropriate. Sometimes the issue is not the OS but the hypervisor - eg OVM 2.x was completely unusable with the JVM due to bugs in time handling. With no simple means to detect when we have a trustworthy gethrtime() we have had to leave the workarounds in place. If resources had been available we would have added this flag a couple of years ago and then looked at making trusting gethrtime() the default, as I think it has been reliable in Solaris for quite some time. Unfortunately we never know when virtualized evironments will break the OS.
11-07-2016
Adding a flag to Solaris is the wrong solution for Solaris, gethrtime should just be used directly and by default as it is guaranteed to be monotonic: Although the units of hi-res time are always the same (nanoseconds), the actual resolution is hardware dependent. Hi-res time is guaranteed to be monotonic (it won't go backward, it won't periodically wrap) and linear (it won't occasionally speed up or slow down for adjustment, like the time of day can), but not necessarily unique: two sufficiently proximate calls may return the same value. If it can be demonstrated that isn't the case on any Solaris platform it's a Solaris bug and should be logged as such. The JVM should not be attempting to fix an issue that doesn't exist, especially when doing so has a 6x performance penalty.
06-07-2016
It affects SPARC as well.
30-10-2015
Please look at JDK-6868976 when working on this bug.
24-02-2014
EVALUATION See description.
24-07-2009