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