JDK-8218680 : G1 crashes during calculation of old collection set candidates
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 13
  • Priority: P1
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2019-02-08
  • Updated: 2019-02-27
  • Resolved: 2019-02-12
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 13
13 b08Fixed
Related Reports
Relates :  
JDK-8217330 - Split G1CollectionSetChooser into collection set candidate container and the chooser algorithm
Relates :  
JDK-8218975 - Bug in macOSX kernel's pthread support
Description
BigRAMTester crashes after a while after the changes for JDK-8217330 with

Unexpected Error
------------------------------------------------------------------------------
Internal Error at g1CollectionSetChooser.cpp:118, pid=40852, tid=40888
assert(_max_size > result - 1) failed: Array too small, is 644 should be 672 with chunk size 28.
Comments
The problem is that at some point two parameters are messed up: G1BuildCandidateArray(uint max_num_regions, uint num_workers, uint chunk_size) is passed num_workers and chunk_size in class G1BuildCandidateRegionsTask { G1BuildCandidateArray _result; G1BuildCandidateRegionsTask(uint max_num_regions, uint chunk_size, uint num_workers): [...] _result(max_num_regions, chunk_size, num_workers) ... }; This is (I think) not a problem if chunk_size > num_workers, which is most often the case (chunk_size = num_regions / num_workers), but ends badly in this case because there are only 320 regions with 28 workers in the heap (i.e. chunk_size = 23).
08-02-2019