RFR: Performance improvements for non-generational modes
William Kemper
wkemper at openjdk.org
Fri Mar 3 19:11:59 UTC 2023
On Fri, 3 Mar 2023 17:58:09 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:
>> There are a basket of changes here:
>> * Make heuristics a bit less aggressive:
>> * Revert threshold triggers to use `available` rather than adjusted head room.
>> * Remove code that adjusted average gc time, it was causing wild fluctuations and making heuristic behave erratically
>> * Skip over more generational mode constraints on the allocation path
>> * Disable `ShenadoahEvacLABRatio` by default as it causes unused bytes in survivors regions, which in turn leads to these regions to being included in the mutator view of free memory. This contributed to higher fragmentation rates.
>> * More detailed debugging messages under the `gc+free` tags.
>
> src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp line 314:
>
>> 312: range(1.0,100.0) \
>> 313: \
>> 314: product(uintx, ShenandoahMaxEvacLABRatio, 0, EXPERIMENTAL, \
>
> Surprised this would have an effect on single-generation performance. Have we measured the costs/benefits of setting this default differently? If 0 works best, maybe we should remove this entirely?
Yes, it was counter intuitive. This setting causes small chunks of memory to remain free in regions that have otherwise been consumed by gc lab allocations. When the evacuation reserve is exhausted, the collector will steal regions from the mutator. Because of the free memory in these regions, they are retained in the mutator's view of the freeset after the collection is complete. This in turn increases fragmentation in the mutator's view and reduces the amount of available memory to the mutators, causing the triggers to run more often.
I only tested the default setting (16) and turning it off completely. I will test additional values.
-------------
PR: https://git.openjdk.org/shenandoah/pull/220
More information about the shenandoah-dev
mailing list