RFR: 8316226: GenShen: Consider forcing auto-tenure age to be greater than 1 [v2]

Kelvin Nilsen kdnilsen at openjdk.org
Wed Nov 29 16:13:06 UTC 2023


On Wed, 29 Nov 2023 00:41:03 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> I've corrected some off-by-one issues with the existing computation of tenuring age that would cause premature promotion. Also fixed the support for "never tenure" and for an approximation of "always tenure", as well as fixing guardrails around the setting for the controlling flags for min and max tenuring age.
>> 
>> **Epilogue:** Testing with the Extremem configuration from Kelvin indicates that our current strategy for adapting the tenuring threshold based solely on historical mortality on a per-cohort basis falling below a preset is sub-optimal because it doesn't consider the twin costs of premature promotion of objects that might soon die, viz.
>> 1. the shrinkage of young generation and concomitant increase in minor gc cycle frequency
>> 2. the growth of old generation and concomitant increase in the major cycle frequency
>> 
>> The current algorithm tends to reduce the tenuring threshold too rapidly since it does not have much idea of future mortality of cohorts that are either promoted or identified for promotion in earlier cycles (but which may not have been promoted for other considerations such as garbage density). More commentary can be found in the ticket.
>> 
>> Specifically for the Extremem workload, we found that flipping the current setting of `ShenandoahGenerationalCensusIgnoreOldCohorts` to false softened this effect somewhat and improved the tenuring behavior a little, although it didn't match min=15,max=15, or min=7,max=7. The specjbb configuration wasn't affected much because objects didn't display long lifetimes and the current algorithm was able to find the appropriate low tenuring age (in reality varying the tenuring age made little difference here, although with smaller fixed size younger generations, it might start to show a difference).
>> 
>> As a result of all of this, I am planning to just check-in a minimal change for now, while I investigate further tweaks to this algorithm in a separate PR. In particular, to avoid sudden and surprising changes in behavior, I am still leaving `ShenandoahGenerationalCensusIgnoreOldCohorts` at its current `true` setting for now, although flipping it showed some benefits with the Extremem workload.
>> 
>> **Testing:**
>> - GHA & Codepipeline tests on x86 and aarch64
>> - also tested (including performance) with specjbb2015 and with extremem with default settings, min=2, min=max=7, min=max=15, never ternure (min=max=16), always tenure (min=max=1)
>
> Y. Srinivas Ramakrishna has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 21 additional commits since the last revision:
> 
>  - Merge branch 'master' into min_tenuring
>  - Don't promote objects in the cohort that has high mortality; instead
>    use the next older age to avoid premature promotion.
>  - Merge branch 'master' into min_tenuring
>  - Merge branch 'master' into min_tenuring
>  - We aren't currently set up to promote age 0 objects. Place a floor of 1
>    under the tenuring ages.
>  - Correct a documentation comment
>  - Comments in shenandoah_globals.hpp
>  - Fix more edge cases
>  - Merge branch 'master' into min_tenuring
>  - Fix another couple of off-by-1's
>  - ... and 11 more: https://git.openjdk.org/shenandoah/compare/2786570c...fb54fdd1

Marked as reviewed by kdnilsen (Committer).

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

PR Review: https://git.openjdk.org/shenandoah/pull/359#pullrequestreview-1755659982


More information about the shenandoah-dev mailing list