RFR 6523160: RuntimeMXBean.getUptime() returns negative values

[Jaroslav Bachorik]

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-