RFR 6523160: RuntimeMXBean.getUptime() returns negative values

[David Holmes]

On 9/10/2013 9:26 PM, Jaroslav Bachorik 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.

Only nit with this is that you initialize _begin_vm_creation_ns very 
early compared to the other timestamps. Plus I'm not even certain when 
this global initializer will execute relative to the VM initialization 
sequence! Best to move it into Management::init() to where 
_begin_vm_creation_time is initialized.

David
-----

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