JDK-6298653 : Use finest granularity clock (System.nanoTime) for sleep, wait, util.Timer ...
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.lang
  • Affected Version: 5.0
  • Priority: P4
  • Status: Closed
  • Resolution: Not an Issue
  • OS: linux
  • CPU: x86
  • Submitted: 2005-07-19
  • Updated: 2018-09-26
  • Resolved: 2018-09-26
Related Reports
Relates :  
JDK-5068368 - (thread) Thread.sleep should say "at least as long" and implement this guarantee
Relates :  
JDK-6189055 - (timer) Add nanosecond support to java.util.Timer
Relates :  
JDK-4373068 - Thread.sleep() does not work as expected in Solaris.
Description
A DESCRIPTION OF THE REQUEST :
Currently two clock granularities exist in the Linux hotspot version.  One that is more coarse grain for the methods on an Object like wait, and on a Thread like sleep, and util.Timer framework.  The other new System.nanoTime uses the more fine grained clock.  It would provide consistency to use the finest grain clock for all timing related activities.

 NOTE:  It also would improve the JVM to implement System.nanosecond method using the POSIX Clock_gettime() call rather than the get time of day call.  Clock_gettime returns a more fine clock granularity.

JUSTIFICATION :
Having two differing clocks in the JVM is misleading and can be error prone.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
One clock of the finest granularity permitted by the operating system driving the JVM.
###@###.### 2005-07-19 11:43:31 GMT
Comments
This seems a VM runtime issue not a library or API issue. We have so many time/timer related bugs/ref's that it is somewhat daunting and it would be good to close out a number of these. I don't think this CR is actually asking for something that is deliverable. The requestor is confusing the two different kinds of time mechanisms available in a system: - ways to measure elapsed time - ways to have time-trigerred events The resolution of the "timers" used for these two things are normally quite different. Typically you can read a time (or a value that can be related to a time) at a much higher resolution (nanos or micros) than you can generate a time-related event (typically many milliseconds eg 10ms timer tick). Even though the hardware permits it, the OS typically constrains it to "reasonable" values. You don't (as has been pointed out above) get operating systems making scheduling decisions every micro or nano-second. A sleep() with nanosecond "resolution" isn't provided by the OS. The VM should always use the best available mechanism on a given OS for these time/timer related API's. What we should avoid however is trying to duplicate part of the OS to provide time/timer functionality beyond that given by the OS. Solaris's time functionality is quite good. As linux implements the Posix clock_gettime functionality for both CLOCK_REALTIME and CLOCK_MONOTONIC, its time/timer code gets better. Windows is a complex mess.
26-09-2018
EVALUATION Doug Lea writes: ----------------------------------------------------------------- See hotspot/src/os/linux/vm/os_linux.cpp, where I wrote about two years ago the scaffolding for this. All that remains is to do the indicated detection, which is not much fun, but probably not hard. #define JAVA_TIME_NANOS_USES_CLOCK_GETTIME 0 jlong os::javaTimeNanos() { #if JAVA_TIME_NANOS_USES_CLOCK_GETTIME // Recent linux libraries support clock_gettime, which is preferable // here, but only if CLOCK_MONOTONIC is supported, which it is not in // most distributions as of this writing. When it is, the following // code that uses can be used. For now, it just uses gettimeofday. // Also, some sort of auto-detection should be used to trigger it. - dl struct timespec tp; int status = clock_gettime(CLOCK_MONOTONIC, &tp); assert(status == 0, "gettime error"); jlong result = jlong(tp.tv_sec) * (1000 * 1000 * 1000) + jlong(tp.tv_nsec); return result; #else timeval time; int status = gettimeofday(&time, NULL); assert(status != -1, "linux error"); jlong usecs = jlong(time.tv_sec) * (1000 * 1000) + jlong(time.tv_usec); return 1000 * usecs; #endif } The above only addresses the request > Use finest granularity clock (System.nanosecond) for sleep, wait, util.Timer ... ----------------------------------------------------------------- Fixing this might be a joint hotspot-library venture, so I'll add some hotspotters to the interest list -------------------------------------------------------------------- Regarding the other request: > ============================================================ > DESCRIPTION OF THE REQUEST : Currently two clock granularities exist > in the Linux hotspot version. One that is more coarse grain for the > methods on an Object like wait, and on a Thread like sleep, and > util.Timer framework. The other new System.nanosecond uses the more > fine grained clock. It would provide consistency to use the finest > grain clock for all timing related activities. This request is already addressed in various ways. For example the TimeUnit class supports timed wait and sleeps using standardized precision arguments. (The actual precision of any given sleep or wait is a complicated issue though, for which no few guarantees are made or can be made.) ###@###.### 2005-07-19 16:59:27 GMT
19-07-2005