RFR: 8314599: [GenShen] Couple adaptive tenuring and generation size budgeting

[William Kemper]

Notable changes:
* Improvements to logging
* More accurate tracking of promotion failures
* Use shared allocation for promotions only when the size is above the maximum plab size (not the minimum size)
* Use census information gathered during mark to size promotion reserves and old generation

With these changes, GenShen is expected to have fewer promotion failures and this is indeed the case. As a result of this, we expect less time to be spent in concurrent marking and update refs for young collections. We may also expect shorter concurrent evacuation phases because GenShen will have fewer densely packed regions stuck in the young generation. With more objects being promoted, we also expect to see longer remembered set scan times. This is generally the case across all benchmarks, but we do also see some counter-intuitive results.

Here we are comparing 20 executions (10 on x86, 10 on aarch64) of the changes in the PR (experiment) against 20 executions of the same benchmarks results from tip. This is a summary of statistically significant changes of more than 5% across all benchmarks:


Concurrent Evacuation: 7 improvements, 3 regressions
• Best improvements: extremem-large-45g (-29.6%), neo4j-analytics (-26.9%)
• Worst regression: xalan (+53.7%)

Concurrent Marking: 15 improvements, 1 regression  
• Best improvements: hyperalloc_a2048_o4096 (-30.1%), crypto.rsa (-27.3%)
• Only regression: serial (+8.9%)

Concurrent Scan Remembered Set: 7 improvements, 2 regressions
• Best improvements: xalan (-49.4%), pmd (-49.0%), crypto.rsa (-41.8%)
• Worst regression: extremem-phased (+52.4%)

Concurrent Update Refs: 5 improvements, 4 regressions
• Best improvements: crypto.rsa (-36.4%), mnemonics (-28.4%)
• Worst regression: xalan (+89.4%)

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

Commit messages:
 - Little cleanup
 - Fix wrong asserts
 - Only use old generation in generational mode
 - More accurate method names for cset fields, consider promotion reserves when computing excess old regions
 - Merge fallout
 - Merge remote-tracking branch 'jdk/master' into promotion-budget-improvements
 - Merge remote-tracking branch 'jdk/master' into promotion-budget-improvements
 - Tweak comment
 - Merge remote-tracking branch 'jdk/master' into make-evac-tracking-runtime-option
 - Merge remote-tracking branch 'earthling-jdk/adaptive-tenuring-threshold' into make-evac-tracking-runtime-option
 - ... and 42 more: https://git.openjdk.org/jdk/compare/648582ab...fd9619dd

Changes: https://git.openjdk.org/jdk/pull/27632/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27632&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8314599
  Stats: 292 lines in 16 files changed: 145 ins; 72 del; 75 mod
  Patch: https://git.openjdk.org/jdk/pull/27632.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27632/head:pull/27632

PR: https://git.openjdk.org/jdk/pull/27632