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