JDK-8252041 : G1: Fix incorrect uses of HeapRegionManager::max_length
- Type: Bug
- Component: hotspot
- Sub-Component: gc
- Affected Version: 16
- Priority: P4
- Status: Resolved
- Resolution: Fixed
- Submitted: 2020-08-19
- Updated: 2024-11-22
- Resolved: 2020-09-17
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.
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 16 |
|---|
16 b17Fixed  |
Related Reports
|
Blocks :
|
|
|
Relates :
|
Description
Since the implementation of JDK-8171181 JEP 316: Heap Allocation on Alternative Memory Devices there are two notions of maximum number of regions in the heap in HeapRegionManager: max_length(): maximum number of regions in the entire reserved area of the heap (to be used for sizing for arrays etc.) max_expandable_length(): maximum number of regions g1 is allowed to commit. There are some wrong uses of both. This is not an issue for regular G1 as both are the same, but a problem when having a larger reserved space than committable (e.g. with that feature enabled). There are also some missing bounds checks in the code assuming max_length == max_expandable_length. Fix this (and users of HeapRegionManager::max_length/max_expandable_length)
Comments
|