On 8.10.2013 09:34, David Holmes wrote:
Jaroslav,
On 2/10/2013 6:47 PM, Jaroslav Bachorik wrote:
Hello,
currently the JVM uptime reported by the RuntimeMXBean is based on
System.currentTimeMillis() which makes it susceptible to changes of the
OS time (eg. changing timezone, NTP synchronization etc.). The uptime
should not depend on the system time and should be calculated using a
monotonic clock source.
There is already the way to get the actual JVM uptime in ticks. It is
accessible as Management::timestamp() and the ticks are convertible to
milliseconds using Management::ticks_to_ms(ts_ticks) thus making it very
easy to switch to the monotonic clock based uptime.
Maybe I'm missing something but TiumeStamp updates using
os::elapsed_counter() which on Linux uses gettimeofday so is not a
monotonic clock source.
Hm, yes. I wasn't aware of this linux/bsd specific.
Is there any reason why a non monotonic clock source is used for
timestamping except of the historical one? os::javaTimeNanos() uses
montonic clock when available - why can't be the same used for
os::elapsed_counter() especially when a counter based on "gettimeofday"
is not really a counter?
-JB-
David
-----
The patch consists of the hotspot and jdk parts.
For the hotspot a new constant needs to be introduced in
src/share/vm/services/jmm.h and the actual logic to obtain the uptime in
milliseconds is added in src/share/vm/services/management.cpp.
For the jdk the changes comprise of adding the necessary JNI bridging
methods in order to get the new uptime, introducing the same constant
that is used in hotspot and changes to mapfile-vers files in order to
properly build the native library.
Issue: https://bugs.openjdk.java.net/browse/JDK-6523160
Webrev: http://cr.openjdk.java.net/~jbachorik/6523160/webrev.00
Thanks,
-JB-
