negative timings in GC log

Kirk Pepperdine kirk at
Fri Feb 21 13:51:29 UTC 2014

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. 


On Feb 21, 2014, at 10:34 AM, Mikael Gerdin <mikael.gerdin at> 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.
> 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>:
>>> 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

More information about the hotspot-gc-dev mailing list