negative timings in GC log

[Kirk Pepperdine]

Hi all,

Cool then something that we don’t have to worry about so much going forward! In the meantime I can correct the calculation with a guestimation. 

Regards,
Kirk

On Feb 21, 2014, at 10:34 AM, Mikael Gerdin <mikael.gerdin at oracle.com> wrote:

> On Friday 21 February 2014 10.09.21 Bernd Eckenfels wrote:
>> Just a BTW: NTPd is known to not cause those problems as it does not "step"
>> the clock, this does more happen if you use ntpdate in cron or the VMTools.
>> I would advice against both in Java systems.
>> 
>> However I wonder if - similar to other timed primitives - it is time to
>> reconsider switching of the clock source for those timings?
> 
> This has in fact been done in 8.
> The following change makes the VM use CLOCK_MONOTONIC for the 
> os::elapsed_counter which is used for the GC duration times.
> 
> https://bugs.openjdk.java.net/browse/JDK-8027294
> 
> However, there are quirks with CLOCK_MONOTONIC. See the man page for 
> clock_gettime(3).
> 
> /Mikael
> 
>>> Am 21.02.2014 um 09:27 schrieb Kirk Pepperdine <kirk at kodewerk.com>:
>>> 
>>> Hi all,
>>> 
>>> More of an FYI but I sometimes run across things that look like this.
>>> 
>>> [PSYoungGen: 2096928K->64K(2097024K)] 3981201K->1884337K(4194176K),
>>> -0.2652920 secs] [Times: user=0.04 sys=0.00, real=0.02 secs]
>>> 
>>> This is coming from a 1.7.0 JVM but I fear I won’t be able to determine
>>> the exact build. The JVM was running in a virtualized environment. My
>>> guess is something like this could happen if something (NTP?) has diddled
>>> with the clock. My question is, would it be better to leave it as is or
>>> report it as 0 or unknown?
>>> 
>>> Regards,
>>> Kirk
>