JDK-8031686 : G1: assert(_hrs.max_length() == _expansion_regions) failed
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: hs25
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2014-01-14
  • Updated: 2017-07-26
  • Resolved: 2014-01-28
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 8 JDK 9
8u60Fixed 9 b03Fixed
Description
Nightly testing for 2014-01-07 triggered the follwoing assert:

#  Internal Error (/opt/jprt/T/P1/155441.amurillo/s/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp:2069), pid=6893, tid=4152105840
#  assert(_hrs.max_length() == _expansion_regions) failed: max length: 14784 expansion regions: 2496

This is in G1CollectedHeap::initialize() while we are setting up  the heap.

 _hrs.max_length() contains the number of regions that we have set up. 
_expansion_regions represents the number of regions based on MaxHeapSize.

The assert says that these values should be the same, which of course makes sense. In this case we have  _hrs.max_length() > _expansion_regions, which looks like we for some reason set up more regions than was required to cover the MaxHeapSize.


Impact=M, the crash happens at startup. No loss of data.
Likelihood=L, we have not seen this before so it is likely that this has to do with some condition on the specific machine. Low memory?
Workaround=H, Unknown at the moment.

ILW=MLH -> P4
Comments
Regression test exists.
26-07-2017
Release team: Approved for deferral.
16-01-2014
8-defer-request justification: This is not a show stopper, the affect this bug will have on a product build is that it will use more memory than needed and the jmap-tool will report to many regions when querying for heap summary. We have a fix ready and will try to get it into 9 and 8u20 as soon as possible.
15-01-2014
The erroneous calculation will end up setting the wrong value for HeapRegionSeq::max_lenght(), this method is mostly used for assertion statements but it is also used for returning G1CollectedHeap::max_regions(). I've looked through the use of this function together with Bengt and from what we can see there is no risk for crashing due to this, but we will end up using more memory. ILW => MHH => P2 Impact: Medium, we only fail during initialization in debug builds. For product we will use more memory for meta data. Likelihood: High, happens every time. Workaround: High, use less heap is the only workaround and it might not be good enough for a lot of cases.
15-01-2014
This is a regression, no problem with 7u40.
15-01-2014
Great find, Stefan. Thanks for the update!
14-01-2014
This is only an issue using 32-bit VMs. In G1BiasedMappedArrayBase::initialize() this calculation overflows when MaxHeapSize is larger than 2g: size_t num_target_elems = (end - bottom) / (mapping_granularity_in_bytes / HeapWordSize); Switching that calculation to use pointer_delta instead will solve the problem: size_t num_target_elems = pointer_delta(end, bottom, mapping_granularity_in_bytes);
14-01-2014
Also, running with the same command line as in the failing test passes: $ jdk1.8.0/fastdebug/bin/java -Xmixed -XX:MaxRAMFraction=8 -XX:+CreateMinidumpOnCrash -XX:+UseG1GC -XX:MaxHeapSize=2617245696 -XX:OldSize=1744830464 -XX:MaxMetaspaceSize=128m -version java version "1.8.0-ea-fastdebug" Java(TM) SE Runtime Environment (build 1.8.0-ea-fastdebug-b121) Java HotSpot(TM) 64-Bit Server VM (build 25.0-b63-fastdebug, mixed mode)
14-01-2014
Interesting. It does not reproduce for me with b121. Which build were you using? $ uname -a Linux spb23184 2.6.39-400.21.1.el6uek.x86_64 #1 SMP Thu Apr 4 03:49:00 PDT 2013 x86_64 x86_64 x86_64 GNU/Linux $ jdk1.8.0/fastdebug/bin/java -Xmixed -XX:+UseG1GC -Xmx2048m -version java version "1.8.0-ea-fastdebug" Java(TM) SE Runtime Environment (build 1.8.0-ea-fastdebug-b121) Java HotSpot(TM) 64-Bit Server VM (build 25.0-b63-fastdebug, mixed mode)
14-01-2014
Reproducible on spb23184.ru.oracle.com by running: jdk1.8.0/fastdebug/bin/java -Xmixed -XX:+UseG1GC -Xmx2048m -version -Xmx2047 is also failing but -Xmx2046 is ok, this is very close to 2g so there might be some miscalculation or something here. I will continue investigating.
14-01-2014
Link to the aurora job and rules from it: http://aurora.ru.oracle.com/functional/faces/RunDetails.xhtml?names=343047.JAVASE.NIGHTLY.VM.Main_Baseline_jdk8.2014-01-07-171 RULE tmtools/jmap/heap_config/jmap_heap_config_huge_OldSize_live Crash Internal Error ...g1CollectedHeap.cpp...assert(_hrs.max_length() == _expansion_regions) failed: max length: ... expansion regions: ... RULE tmtools/jmap/heap_config/jmap_heap_config_huge_MaxHeapSize_core Crash Internal Error ...g1CollectedHeap.cpp...assert(_hrs.max_length() == _expansion_regions) failed: max length: ... expansion regions: ... RULE tmtools/jmap/heap_config/jmap_heap_config_huge_MaxHeapSize_live Crash Internal Error ...g1CollectedHeap.cpp...assert(_hrs.max_length() == _expansion_regions) failed: max length: ... expansion regions: ... RULE tmtools/jmap/heap_config/jmap_heap_config_huge_MaxNewSize_core Crash Internal Error ...g1CollectedHeap.cpp...assert(_hrs.max_length() == _expansion_regions) failed: max length: ... expansion regions: ... RULE tmtools/jmap/heap_config/jmap_heap_config_huge_MaxNewSize_live Crash Internal Error ...g1CollectedHeap.cpp...assert(_hrs.max_length() == _expansion_regions) failed: max length: ... expansion regions: ... RULE tmtools/jmap/heap_config/jmap_heap_config_huge_NewSize_core Crash Internal Error ...g1CollectedHeap.cpp...assert(_hrs.max_length() == _expansion_regions) failed: max length: ... expansion regions: ... RULE tmtools/jmap/heap_config/jmap_heap_config_huge_NewSize_live Crash Internal Error ...g1CollectedHeap.cpp...assert(_hrs.max_length() == _expansion_regions) failed: max length: ... expansion regions: ... RULE tmtools/jmap/heap_config/jmap_heap_config_huge_OldSize_core Crash Internal Error ...g1CollectedHeap.cpp...assert(_hrs.max_length() == _expansion_regions) failed: max length: ... expansion regions: ...
14-01-2014