-
Bug
-
Resolution: Fixed
-
P4
-
15
-
b04
// We will try our best not to "eat" into the reserve.
uint absolute_max_length = 0;
if (_free_regions_at_end_of_collection > _reserve_regions) {
absolute_max_length = _free_regions_at_end_of_collection - _reserve_regions;
}
I.e. if the amount of free regions is larger than the regions in the reserve, try to allocate until the start of the reserve. (Which is debatable, as the reserve itself is supposed to be used...)
However this misses the situation when the number of free regions is already smaller than the reserve - in this case the amount of free regions the caller gets is *not* bounded by anything anymore, meaning that the heuristic may hand out more regions than are actually available, i.e. the mutator will use up all available regions.
Which means that G1 will run into evacuation failures, and eventually in a full gc ("Attempting maximally compacting GC") as the evacuation failure handling does not guarantee to free any region.
In some cases this can lead to G1 running into such evacuation failure/full gcs over and over again as this leads to an extremely high old gen allocation rate (ie. the regions where evacuation failed).
Note that the resulting evac failure/full gc is fine - the problem is that the heuristic hands out too many regions all the time, which leads to old gen filling up very quickly (with almost empty regions), not giving the marking enough time to complete.
Adaptive IHOP in these cases can't lower the threshold fast enough in these cases.
- blocks
-
JDK-8238687 Investigate memory uncommit during young collections in G1
-
- Open
-
- relates to
-
JDK-8249676 [REDO] G1 incorrectly limiting young gen size when using the reserve can result in repeated full gcs
-
- Resolved
-
-
JDK-8248650 [BACKOUT] Backout JDK-8244603 because it generates too much noise in CI
-
- Resolved
-
-
JDK-8248329 JDK-8244603 breaks windows build
-
- Resolved
-
-
JDK-8248442 Kitchensink24HStress.java SIGSEGV in G1ParScanThreadState::copy_to_survivor_space due to bad Handle
-
- Closed
-
-
JDK-8248447 SIGSEGV in G1ScanHRForRegionClosure::scan_heap_roots
-
- Closed
-
-
JDK-8254164 G1 only removes self forwarding pointers for last collection set increment
-
- Closed
-
-
JDK-8238858 G1 Mixed gc young gen sizing might cause the first mixed gc to immediately follow the prepare mixed gc
-
- Resolved
-
-
JDK-8253411 [BACKOUT] [REDO] G1 incorrectly limiting young gen size when using the reserve can result in repeated full gcs
-
- Resolved
-