RFR: 8316299: GenShen: Reduce frequency of expedited GC

Aleksey Shipilev shade at openjdk.org
Thu Sep 14 15:29:52 UTC 2023


On Thu, 14 Sep 2023 15:21:53 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> We have found that expedited GCs too frequently yield very little benefit because they occur so soon after the previous GC that there has been no accumulation of garbage.
> 
> The primary motivation for expediting GC is to avoid a situation under which there is so much "promotion" work to be performed that the urgent need to reclaim garbage from young-generation is obstructed by this promotion work.
> 
> This PR ends the practice of expediting to support promotion in place.  The effort required to promote a region in place is minimal and unlikely to contend in a major way with young collection efforts.
> 
> This PR also reduces the likelihood that we will expedite for promotion by evacuation, because it requires the amount of accumulated promo potential to exceed a particular threshold.

Looks okay, but I have a question:

src/hotspot/share/gc/shenandoah/heuristics/shenandoahYoungHeuristics.cpp line 139:

> 137:   ShenandoahHeap* heap = ShenandoahHeap::heap();
> 138: 
> 139:   size_t promo_expedite_threshold = (heap->young_generation()->max_capacity() * ShenandoahEvacReserve) / 512;

What's the reasoning behind `512` divisor here? Since `ShenandoahEvacReserve` is percents of young/total heap size, this makes `promo_expedite_threshold` about 20% of heap size. Is that what we want?

-------------

Marked as reviewed by shade (Committer).

PR Review: https://git.openjdk.org/shenandoah/pull/325#pullrequestreview-1627172704
PR Review Comment: https://git.openjdk.org/shenandoah/pull/325#discussion_r1326128445


More information about the shenandoah-dev mailing list