RFR: 8335126: Shenandoah: Improve OOM handling

Aleksey Shipilev shade at openjdk.org
Thu Jun 27 19:09:18 UTC 2024


On Wed, 26 Jun 2024 17:51:36 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> 1. Throw OOM after failed allocation request following a Full GC (rather
>    than retrying as long as Full GC makes good progress because
>    repeatedly retrying the allocation request creates brown-out behavior
>    with no identified benefits on real-world workloads)
> 
> 2. Count a successful allocation following a blocking
>    handle_allocation_failure() request to be good GC progress.
>    Otherwise, we increment gc_no_progress_count in full GCs that
>    have bad progress but successful allocations, and this causes
>    unwanted failure to even try a full GC in a different thread after
>    an out-of-memory condition might have been resolved in this thread.
> 
> 3. Count a completed concurrent GC cycle as good progress, regardless
>    of how much memory it might have been able to reclaim.  The fact that
>    concurrent GC succeeded without allocation failure and without
>    degeneration is considered good progress.  Successful concurrent
>    GCs between Full GCs will reset the gc_no_progress_count to zero.
> 
> 4. Do not count degenerated cycles as having no-progress.  If a
>    degenerated cycle has no progress, it will upgrade to full GC.
>    The upgraded full GC will evaluate its own progress.  We don't
>    want to count this "same [upgraded] cycle" twice.
> 
> These changes have been tested over a variety of workloads and standard tests.  These changes have also been tested with the generational mode of Shenandoah.  It appears these changes provide more robust and consistent handling across a diversity of scenarios than the original implementation.

All right, this makes sense to me, as long as experiments show this is a good idea as well. But I think the comment should be shorter.

src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 960:

> 958:       //   b) We experienced at least one Full GC (whether or not it had good progress)
> 959:       //
> 960:       // TODO: Rather than require a Full GC before throwing OOMError, it might be more appropriate for handle_alloc_failure()

Pro-tip: If you find yourself writing a large TODO comment, it should probably be transplanted straight into a new issue.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19912#pullrequestreview-2146288690
PR Review Comment: https://git.openjdk.org/jdk/pull/19912#discussion_r1657679558


More information about the hotspot-gc-dev mailing list