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

[Kelvin Nilsen]

On Fri, 31 Oct 2025 00:21:27 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> 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%)
>
> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 60 commits:
> 
>  - Merge remote-tracking branch 'jdk/master' into promotion-budget-improvements
>  - Merge remote-tracking branch 'jdk/master' into promotion-budget-improvements
>  - Merge tag 'jdk-26+20' into promotion-budget-improvements
>    
>    Added tag jdk-26+20 for changeset b5b83247
>  - Proper format bytes in logs for better readability
>  - Merge remote-tracking branch 'jdk/master' into promotion-budget-improvements
>  - Review feedback, bug fixes
>  - Fix windows build more
>  - Fix windows build
>  - Little cleanup
>  - Fix wrong asserts
>  - ... and 50 more: https://git.openjdk.org/jdk/compare/6347f10b...1d81159a

src/hotspot/share/gc/shenandoah/shenandoahGeneration.cpp line 661:

> 659:   const size_t tenurable_next_cycle = heap->age_census()->get_tenurable_bytes(tenuring_threshold - 1);
> 660:   const size_t tenurable_this_cycle = heap->age_census()->get_tenurable_bytes(tenuring_threshold);
> 661: 

I'm wondering if we should subtract tenurable_this_cycle from tenurable_next_cycle.  (and assert that tenurable_this_cycle is <= tenurable_next_cycle)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27632#discussion_r2543694437