RFR 6523160: RuntimeMXBean.getUptime() returns negative values

Jaroslav Bachorik jaroslav.bachorik at oracle.com
Wed Oct 9 04:26:27 PDT 2013


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



More information about the serviceability-dev mailing list