JDK-6959014 : G1: assert(minimum_desired_capacity <= maximum_desired_capacity) failed: sanity check
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: hs19
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2010-06-07
  • Updated: 2013-09-18
  • Resolved: 2011-04-23
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
6u21pFixed 7Fixed hs19Fixed
Related Reports
Relates :  
Description
Fastdebug VM crashes with

# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (C:\BUILD_AREA\jdk7\hotspot\src\share\vm\gc_implementation\g1\g1CollectedHeap.cpp:1052), pid=4264, tid=3692
#  assert(minimum_desired_capacity <= maximum_desired_capacity) failed: sanity check
#
# JRE version: 7.0-b96
# Java VM: Java HotSpot(TM) Client VM (19.0-b02-fastdebug mixed mode windows-x86 )
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp

Stack trace:

V  [jvm.dll+0x3731cc];;  ?report_and_die@VMError@@QAEXXZ+0x4dc
V  [jvm.dll+0x11a6b5];;  ?report_vm_error@@YAXPBDH00@Z+0x45
V  [jvm.dll+0x13c84c];;  ?resize_if_necessary_after_full_collection@G1CollectedHeap@@IAEXI@Z+0x12c
V  [jvm.dll+0x14460f];;  ?do_collection@G1CollectedHeap@@IAEX_N0I@Z+0x55f
V  [jvm.dll+0x1449c6];;  ?satisfy_failed_allocation@G1CollectedHeap@@IAEPAVHeapWord@@I@Z+0x56
V  [jvm.dll+0x377fbd];;  ?doit@VM_G1CollectForAllocation@@UAEXXZ+0x2d
V  [jvm.dll+0x3776e4];;  ?evaluate@VM_Operation@@QAEXXZ+0x74
V  [jvm.dll+0x3764dc];;  ?evaluate_operation@VMThread@@AAEXPAVVM_Operation@@@Z+0x8c
V  [jvm.dll+0x3768e8];;  ?loop@VMThread@@QAEXXZ+0x358
V  [jvm.dll+0x377061];;  ?run@VMThread@@UAEXXZ+0xb1
V  [jvm.dll+0x2c2c34];;  ?java_start@@YGIPAVThread@@@Z+0xb4
C  [msvcr71.dll+0x9565]
C  [kernel32.dll+0x8eccb]
C  [ntdll.dll+0x7d24d]
C  [ntdll.dll+0x7d45f]

Comments
EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/688c3755d7af
17-08-2010

PUBLIC COMMENTS The fix will also include some tidying up to the code that prints out information on the expansion or shrinking of the heap when Verbose and PrintGC are on.
13-08-2010

SUGGESTED FIX Small fixes to deal with the issues enumerated in the Evaluation note.
13-08-2010

EVALUATION There were a few bugs in the code that calculated whether to grow or shrink the heap and by how much after a Full GC (that's where the failing assert is). a) minimum_desired_capacity was adjusted not to be lower than the min heap size: > minimum_desired_capacity = > MAX2(minimum_desired_capacity, > collector_policy()->initial_heap_byte_size()); whereas we should adjust it not to be greater than the max heap size. minimum_desired_capacity is a lower bound. If it falls below the min heap size, it will by default be lower than the current capacity (given that the current capacity should be greater than or equal to the min heap size), so the current capacity will not need to be adjusted. However, we should not try to increase the current capacity passed the max heap size. b) The assert that fires is in the wrong place. It's placed after the minimum_desired_capacity is adjusted according to the max heap size and maximum_desired_capacity is adjusted according to the min heap size and at that point the condition does not hold. The condition should be checked before the adjustment. c) The calculations for minimum_desired_capacity and maximum_desired_capacity could overflow 32-bit size_t's.
13-08-2010