You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Fix PGC edenSurvivalRate overflow issues in CopyForward
The edenSurvivalRate represents the fraction of Eden regions that
survived a PGC (nominally in the range [0.0, 1.0]). An overflow
(rate > 1.0) can cause incorrect heap/Eden size adjustments, producing
unexpected allocation spikes and, in extreme cases, out-of-memory
errors. The issue is not a regression but was exposed by a recent
Eden-resize change.
Four overflow sources are addressed:
1. Incorrect edenCountBeforeCollect (denominator)
During a PGC the heap may expand, triggering an Eden size
recalculation. The newly calculated Eden size can differ
significantly from the size at collection start, making the survival
rate inaccurate. Fix: use copyForwardStats->_edenEvacuateRegionCount
as the denominator instead of getCurrentEdenSizeInRegions(env).
2. Semantic mismatch between edenSurvivorCount and edenEvacuateCount
In the first few PGCs after a GMP, previous Eden survivors are
ADDRESS_ORDERED_MARKED regions with logicalAge == 0. They enter the
evacuate set as non-Eden regions, but their surviving objects spill
into age-0 survivor regions that are counted as Eden survivors.
This can cause _edenSurvivorRegionCount > _edenEvacuateRegionCount.
Fix: add _hasEdenContent to MM_CopyScanCacheVLHGC and
MM_HeapRegionDescriptorVLHGC::_copyForwardData. The flag is set
during copy() when the source region isEden() (ADDRESS_ORDERED),
propagated from cache to region in stopCopyingIntoCache(), and used
in postProcessRegions() to classify survivor regions accurately.
3. Over-counting of Eden survivor regions (shared fresh survivors)
Because Eden and age-0 non-Eden regions share the same compact group,
they can fill the same fresh survivor regions, causing
_edenSurvivorRegionCount to be over-counted. Fix: redistribute
edenSurvivorCount and nonEdenSurvivorCount using _copyBytesEden as a
ceiling-division estimate of the true Eden survivor region count.
4. _scanBytesEden double-counting (cap)
During abort recovery, objects that were partially copied (forwarding
pointer already installed) are scanned again in the source region,
double-counting their bytes in _scanBytesEden. Combined with high
survival rates, alignment waste, or NUMA/hybrid no-evacuation cases,
this can push edenSurvivorCount above edenCountBeforeCollect.
Fix: cap edenSurvivorCount at edenCountBeforeCollect and add an
assertion that thisSurvivalRate <= 1.0.
Signed-off-by: lhu <linhu@ca.ibm.com>
Copy file name to clipboardExpand all lines: runtime/gc_vlhgc/CopyScanCacheVLHGC.hpp
+2Lines changed: 2 additions & 0 deletions
Original file line number
Diff line number
Diff line change
@@ -53,6 +53,7 @@ class MM_CopyScanCacheVLHGC : public MM_CopyScanCache
53
53
uint64_t _lowerAgeBound; /**< lowest possible age of any object in this copy cache */
54
54
uint64_t _upperAgeBound; /**< highest possible age of any object in this copy cache */
55
55
uintptr_t _arraySplitIndex; /**< The index within the array in scanCurrent to start scanning from (meaningful is OMR_COPYSCAN_CACHE_TYPE_SPLIT_ARRAY is set) */
56
+
bool _hasEdenContent; /**< true if at least one object copied into this cache originated from an Eden (ADDRESS_ORDERED) source region */
56
57
57
58
/* Members Function */
58
59
private:
@@ -88,6 +89,7 @@ class MM_CopyScanCacheVLHGC : public MM_CopyScanCache
0 commit comments