RFR: 8349766: GenShen: Bad progress after degen does not always need full gc

Kelvin Nilsen kdnilsen at openjdk.org
Tue Feb 11 03:53:10 UTC 2025


On Tue, 11 Feb 2025 03:31:51 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> In generational mode, only upgrade to full GC from degenerated GC if we've done two degenerated cycles in a row and both indicated bad progress.  Otherwise, start another concurrent GC, which will most likely degenerate also.  But this degenerated cycle will reclaim floating garbage within the young generation much more quickly than a full GC would have done.

Green represents improvement compared to tip.  For runs 3-5, the new code is notably better.  Run 2 is significantly worse in p50, but about equal to tip average at p99.999 and above.  Run 1 is close to averages of tip at p50, but up to 56% above max at higher percentiles.

Most noteworthy is that we were able to significantly reduce the number of Full GCs without causing a crash or OOM.  On this workload, full GCs are known to require approximately 3 s of pause time.  The average degen cycle required 1.4s (102 out of cycle, 142 at roots, 149 at mark, 1 at evac, 28 at update refs).  Note that an upgraded Full GC results in a pause that is the sum of a Full GC plus a degenerated GC.

While there is reason to be concerned about trial two results on the PR code, I expect that unlucky scenario, whatever it was, will be much less likely in the context of in-flight PRs to advance triggering of GC when allocation rates are accelerating and to surge GC workers whenever there is increased risk of degenerated cycles.  Perhaps, we should wait until those other PRs are integrated and then retest.

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

PR Comment: https://git.openjdk.org/jdk/pull/23552#issuecomment-2649744182


More information about the shenandoah-dev mailing list