JDK-6804746 : G1: guarantee(variance() > -1.0,"variance should be >= 0") (due to evacuation failure)
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: hs15
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2009-02-12
  • Updated: 2010-04-04
  • Resolved: 2009-03-18
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 6 JDK 7 Other
6u14Fixed 7Fixed hs14Fixed
Related Reports
Relates :  
JDK-6820321 - G1: Error: guarantee(check_nums(total, n, parts),"all seq lengths should match")
Relates :  
JDK-6817608 - G1: backports of G1 CRs from HS15 to HS14
Description
Nightly testing uncovered this failure:

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/tmp/jprt/P2/B/154324.ap159146/source/src/share/vm/utilities/numberSeq.cpp:177), pid=15885, tid=9
#  Error: guarantee(variance() > -1.0,"variance should be >= 0")
#
# JRE version: 7.0-b46
# Java VM: Java HotSpot(TM) 64-Bit Server VM (15.0-b01-2009-02-10-154324.ap159146.hotspot-g1-allocspec-6700941-fastdebug mixed mode solaris-amd64 )
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
#
Comments
EVALUATION http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/3698e8f47799
28-02-2009
EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/3698e8f47799
25-02-2009
SUGGESTED FIX While investigating this failure I also noticed the following: update_recent_gc_times(end_sec, full_gc_time_sec); This is incorrect as update_recent_gc_time() is expecting the second parameter to be in ms: void G1CollectorPolicy::update_recent_gc_times(double end_time_sec, double elapsed_ms) { The fix is straightforward (as full_gc_time_ms is already calculated): - update_recent_gc_times(end_sec, full_gc_time_sec); + update_recent_gc_times(end_sec, full_gc_time_ms);
12-02-2009
SUGGESTED FIX Revert this change: + if (!evacuation_failed()) { g1_policy()->record_pause_time((end_time_sec - start_time_sec)*1000.0); + } to make sure we correctly set _last_pause_ms, but only update the pause statistics at the end of the pause if the pause didn't have evacuation failure (which was the original intention of the change).
12-02-2009
EVALUATION Even though it looks similar to 6785211 I think the cause is different. The failure in this CR was introduced by 6797754 and in particular this change: + if (!evacuation_failed()) { g1_policy()->record_pause_time((end_time_sec - start_time_sec)*1000.0); + } So, if there was an evacuation failure, record_pause_time() was not called to notify the policy how long the pause time was. As a result the policy will pick up junk if it reads _last_pause_ms (which is the case here), or pick up an incorrect value (if _last_pause_ms) had been set by a previous pause.
12-02-2009