JDK-7129514 : time warp warnings after 7117303
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: hs23
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2012-01-12
  • Updated: 2012-03-24
  • Resolved: 2012-03-24
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7 JDK 8 Other
7u4Fixed 8Fixed hs23Fixed
Related Reports
Relates :  
JDK-7117303 - VM uses non-monotonic time source and complains that it is non-monotonic
Description
Even after fix to 7117303, there are still some time warp warnings which indicate other problem. Note that time difference here is huge.

jstatd started as pid 28160
Java HotSpot(TM) Client VM warning: time warp: 1326343397113 to 23635156878

Java HotSpot(TM) Client VM warning: time warp: 1326346514971 to 13447721758
Comments
EVALUATION http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/d903bf750e9f
22-03-2012
EVALUATION http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/d903bf750e9f
18-02-2012
SUGGESTED FIX Change remaining calls to os::javaTimeMillis() in GC code (used to update _time_since_last_gc or _millis_since_last_gc) to use os::javaTimeNanos() and convert to milliseconds.
14-02-2012
EVALUATION http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/d903bf750e9f
14-02-2012
EVALUATION As David points out - in the changes for 7117303, I missed a few calls to os::javaTimeMillis() in the GC code (specifically associated with updating the _time_of_last_gc field in the different generation types. I believe that they can all be changed to us an alternative to os::javaTimeMillis().
13-01-2012
EVALUATION It appears that various parts of the GC code still use os::javaTimeMillis to record GC times. These are not comparable with the value of javaTimeNanos() converted to ms that was put in place by 7117303. ./share/vm/memory/genMarkSweep.cpp: gch->update_time_of_last_gc(os::javaTimeMillis()); ./share/vm/memory/defNewGeneration.cpp: update_time_of_last_gc(os::javaTimeMillis()); ./share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp: update_time_of_last_gc(os::javaTimeMillis()); ./share/vm/gc_implementation/parNew/parNewGeneration.cpp: update_time_of_last_gc(os::javaTimeMillis()); However it may be that GC times are expected to correlate to time-of-day values, which would mean we have a basic conflict in how these timestamps are used as they can not be both time-of-day values and monotonic.
12-01-2012