RFR: 8316226: GenShen: Consider forcing auto-tenure age to be greater than 1
Y. Srinivas Ramakrishna
ysr at openjdk.org
Tue Nov 28 18:18:23 UTC 2023
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)
-------------
Commit messages:
- Don't promote objects in the cohort that has high mortality; instead
- 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
- 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
- MinTenuringAge cannot be less than 1
- ... and 10 more: https://git.openjdk.org/shenandoah/compare/d80a17d5...7cb1d459
Changes: https://git.openjdk.org/shenandoah/pull/359/files
Webrev: https://webrevs.openjdk.org/?repo=shenandoah&pr=359&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8316226
Stats: 48 lines in 2 files changed: 29 ins; 0 del; 19 mod
Patch: https://git.openjdk.org/shenandoah/pull/359.diff
Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/359/head:pull/359
PR: https://git.openjdk.org/shenandoah/pull/359
More information about the shenandoah-dev
mailing list