RFR: 8311883: [Genshen] Adaptive tenuring threshold [v11]

[Y. Srinivas Ramakrishna]

On Mon, 14 Aug 2023 20:58:25 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> JDK-8311883 [GenShen] Adaptive tenuring
>> 
>> I am opening this previously draft PR for formal preliminary review. It has already benefited from review feedback from a code walkthrough of an earlier version of the code. Most of that feedback and the corrections thereof are to be found in the comments in this PR. I have addressed a large majority of those comments, and am working on the last one that I plan to address as part of this PR. For the ones that I don't plan to address in this PR, I will create follow up tickets. Those will be added in the responses for the remaining feedback comments recorded in this PR's conversation.
>> 
>> Preliminary testing w/SPECjbb didn't yield reliable performance data from which to infer any performance improvements stemming from enabling adaptive tenuring. I believe that was because of the way SPECjbb is run, which causes excessive degenerate and full gc's. I plan to collect SPECjbb numbers with a fixed lower max HBIR so as to be able to discern performance differences from this change, as well as Extremem workloads. Those will be added here once ready over the next few days.
>
> Y. Srinivas Ramakrishna has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 82 commits:
> 
>  - Merge branch 'master' into adaptive_tenuring
>  - Merge branch 'master' into adaptive_tenuring
>  - Reposition a mis-positioned assert as well as surrounding if-test order.
>  - Fix global flags to make adaptive tenuring with census at mark the
>    default, along with ignoring mortality rates of cohorts older than the
>    selected tenuring age at previous epoch.
>  - Flag to ignore mortality rate of cohorts older than the tenuring age of
>    most recent preious cycle when computing new tenuring threshold.
>  - Clear partial census data before a new marking cycle.
>    Allow consideration of mortality rate of youngest cohort for tenuring
>    decisions. (It was previously excluded because census data didn't
>    include the youngest cohort allocated in the current epoch.)
>    
>    Still to do: avoid tenuring revisionism a la Kelvin's suggestion.
>  - jcheck whitespace.
>  - Merge branch 'master' into adaptive_tenuring
>  - Separate out clearing and testing of local and global portions of census
>    data, towards expunging partial/interrupted census data as a next step.
>  - Merge branch 'master' into adaptive_tenuring
>  - ... and 72 more: https://git.openjdk.org/shenandoah/compare/a4f6425e...13fa9ac9

> JDK-8311883 [GenShen] Adaptive tenuring
> 
...
> Preliminary testing w/SPECjbb didn't yield reliable performance data from which to infer any performance improvements stemming from enabling adaptive tenuring. I believe that was because of the way SPECjbb is run, which causes excessive degenerate and full gc's. I plan to collect SPECjbb numbers with a fixed lower max HBIR so as to be able to discern performance differences from this change, as well as Extremem workloads. Those will be added here once ready over the next few days.


Update on performance efforts:

I've run SPECjbb and Extremem under various configurations of the benchmarks and of Generational Shenandoah in order to separate the performance of reference and specimen. Unfortunately, it appears as if the triggering mechanisms often cause degenerate collections which has been a bit of a challenge to completely eliminate. This appears to inject enough variability into the results that any differences in performance between the two is difficult to discern. 

SPECjbb configurations included fixed preset IR among others, and Extremem configurations (thanks to Kelvin for advice) included various load characteristics. Generational Shenandoah configurations included guaranteed collection interval triggers (variously and in combination for young & old), and disabling garbage density as a criterion for inclusion in the collection set.

The only configuration in which I was able to fully eliminate degenerate GCs for these workloads was Extremem "hefty load" with a 45 g heap. This produced exactly one degenerate GC in each case during the early part of the run. Setting a guaranteed collection interval eliminated this degenerate collection.

A comparison was then made for the time in each of the concurrent phases, both total and average over all cycles. The differences were a wash.

The performance numbers for adaptive tenuring were based on the default settings to be found in
src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp.

While no positive or negative performance impacts have yet been measured, the framework is now in place to allow further experimentation in the future in order to investigate and potentially extract any potential benefits from adaptive tenuring.

I'm happy to integrate this now, or do further future experiments, including coupling this with the size budgeting for generations to demonstrate impact before this goes in. I am open to any and all suggestions.

I'll attach to the ticket the design document upon which the current adaptive tenuring is based, and where we discuss some alternatives and some pitfalls we encountered along the way.

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

PR Comment: https://git.openjdk.org/shenandoah/pull/289#issuecomment-1679357909