JDK-6886024 : G1: assert(recent_avg_pause_time_ratio() < 1.00,"All GC?")
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: hs17
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2009-09-26
  • Updated: 2013-09-18
  • Resolved: 2009-11-11
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
6u18Fixed 7Fixed hs16Fixed
Related Reports
Relates :  
Relates :  
Relates :  
Relates :  
Here's an example log of the failure:-


In particular:-

VM Arguments:
jvm_args: -Xmixed -XX:-UseCompressedOops -XX:-PrintVMOptions -XX:+UnlockExperimentalVMOptions -XX:+UseG1GC -XX:-UseGCOverheadLimit 
java_command: nsk.sysdict.vm.stress.btree.btree010 5 default /export/local/common/testbase/6/vm/vm/bin/jars/nsk/sysdict/share/btree.jar -waittime=5

Failing tests are:-

<fill in more>

EVALUATION http://hg.openjdk.java.net/hsx/hsx16/master/rev/e3c995ac8078

EVALUATION http://hg.openjdk.java.net/hsx/hsx16/baseline/rev/e3c995ac8078

EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/fc06cd9b42c7

EVALUATION As I thought, it turns out that the ratio is becoming 1.0 for this particular benchmark (on some machines, the Full GC overhead is way too high). So, the assert is actually incorrect. BTW, I can also reproduce it on Solaris.

EVALUATION I ran it on a Solaris box (as this is what I have available) and I could not reproduce the crash. However, I looked at the GC log. Here's a fragment (I attached the whole log on the CR): 259.918: [Full GC 1270M->1270M(2016M), 0.6834017 secs] 260.602: [Full GC 1270M->1270M(2016M), 0.6742673 secs] 261.277: [Full GC 1270M->1270M(2016M), 0.6316673 secs] 261.909: [Full GC 1270M->1270M(2016M), 0.6753306 secs] 262.586: [Full GC 1270M->1270M(2016M), 0.6734719 secs] So, it looks to me that the execution IS full of full GCs. So, if the floating point value goes mildly over 1.0 or gettimeofday is slightly incorrect, I can see how this guarantee would fire.