jmx-dev RFR 6523160: RuntimeMXBean.getUptime() returns negative values

[Staffan Larsen]

There is now an awful amount of different timestamps in the Management class. Can they be consolidated somehow? At least _begin_vm_creation_time and the new _begin_vm_creation_ns.

This discussion also implies that the "elapsed time" we print in the hs_err file is also wrong. It uses os::elapsedTime() which uses os::elapsed_counter().

And I guess the same thing for the VM.uptime Diagnostic Command (class VMUptimeDCmd) which also relies on os::elapsed_counter().

/Staffan


On 9 okt 2013, at 13:26, Jaroslav Bachorik <jaroslav.bachorik at oracle.com> wrote:

> On 8.10.2013 23:46, David Holmes wrote:
>> 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.
> 
> My attempt at this is at http://cr.openjdk.java.net/~jbachorik/6523160/webrev.01/hotspot
> I am using os::javaTimeNanos() to get the monotonic ticks where possible.
> 
> The JDK part stays the same as for webrev.00
> 
> -JB-
> 
>> 
>> 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-
>>> 
>