RFR 6523160: RuntimeMXBean.getUptime() returns negative values

[David Holmes]

On 8/10/2013 10:36 PM, Jaroslav Bachorik wrote:
> 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?

It is all historical. These elapsed_counters and elapsed_timers make me 
cringe. But changing it has a lot of potential consequences because of 
the way these are used in logging etc. Certainly not something to be 
contemplated at this stage of JDK 8.

Perhaps a simpler fix here is to expose a startUpTimeNanos that can then 
be used for the uptime.

David

> -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-
>