JDK-8314935 : Shenandoah: Unable to throw OOME on back-to-back Full GCs
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 17,21,22
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2023-08-24
  • Updated: 2024-01-08
  • Resolved: 2023-09-13
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 21 JDK 22
21.0.2Fixed 22 b15Fixed
Related Reports
Relates :  
JDK-8309034 - NoClassDefFoundError when initializing Long$LongCache
Relates :  
JDK-8316632 - Shenandoah: Raise OOME when gc threshold is exceeded
Description
If you run existing tier1 tests with Shenandoah, then this would show up:

```
% CONF=macosx-aarch64-server-fastdebug make test TEST=runtime/ClassInitErrors/TestOutOfMemoryDuringInit.java TEST_VM_OPTS="-Xlog:gc:file=/tmp/gc.log -XX:+UseShenandoahGC"

...


TEST RESULT: Error. Program `/Users/shipilev/Work/shipilev-jdk/build/macosx-aarch64-server-fastdebug/images/jdk/bin/java' timed out (timeout set to 480000ms, elapsed time including timeout handling was 491523ms).
```

The GC log would give the never-ending cycle of Full GCs, never actually throwing OOME:

```
[48.620s][info][gc] Trigger: Handle Allocation Failure
[49.001s][info][gc] GC(64) Cancelling GC: Allocation Failure During Evacuation
[49.002s][info][gc] GC(64) Cannot finish degeneration, upgrading to Full GC
[49.522s][info][gc] GC(64) Pause Degenerated GC (Outside of Cycle) 62M->62M(64M) 901.858ms
[49.522s][info][gc] Failed to allocate TLAB, 3096B
[49.522s][info][gc] Cancelling GC: Allocation Failure
[49.523s][info][gc] Trigger: Handle Allocation Failure
[49.921s][info][gc] GC(65) Cancelling GC: Allocation Failure During Evacuation
[49.923s][info][gc] GC(65) Cannot finish degeneration, upgrading to Full GC
[50.389s][info][gc] GC(65) Pause Degenerated GC (Outside of Cycle) 62M->62M(64M) 865.560ms
[50.389s][info][gc] Failed to allocate Shared, 24B
[50.389s][info][gc] Cancelling GC: Allocation Failure
[50.390s][info][gc] Trigger: Handle Allocation Failure
[50.908s][info][gc] GC(66) Pause Full 62M->62M(64M) 517.640ms
[50.908s][info][gc] Failed to allocate TLAB, 3184B
[50.908s][info][gc] Cancelling GC: Allocation Failure
[50.910s][info][gc] Trigger: Handle Allocation Failure
```

Similar thing seems to happen with `compiler/uncommontrap/TestDeoptOOM.java`
Comments
Apologies.
14-09-2023
[~wkemper] Alexsey is correct. It can (and did) cause some bot confusion. For future reference, it is never the right thing to do to reopen a bug that has been resolved as Fixed with a pushed commit.
14-09-2023
You have to submit a new bug. This one is already resolved and even has backports. I think bots would even barf when seeing the attempt to backport the unresolved issue.
12-09-2023
Re-opening to investigate.
12-09-2023
Unfortunately, the failure still reproduces even after the fix. $ CONF=macosx-aarch64-server-fastdebug make test TEST=runtime/ClassInitErrors/TestOutOfMemoryDuringInit.java TEST_VM_OPTS="-Xlog:gc:file=/tmp/gc.log -XX:+UseShenandoahGC" ... <timeout> GC log still says: ``` ... [116.035s][info][gc] GC(167) Cancelling GC: Allocation Failure During Evacuation [116.037s][info][gc] GC(167) Cannot finish degeneration, upgrading to Full GC [116.507s][info][gc] GC(167) Pause Degenerated GC (Outside of Cycle) 63M->63M(64M) 774.624ms [116.507s][info][gc] Failed to allocate Shared, 16B [116.507s][info][gc] Cancelling GC: Allocation Failure [116.508s][info][gc] Trigger: Handle Allocation Failure [116.867s][info][gc] GC(168) Cancelling GC: Allocation Failure During Evacuation [116.869s][info][gc] GC(168) Cannot finish degeneration, upgrading to Full GC [117.369s][info][gc] GC(168) Pause Degenerated GC (Outside of Cycle) 63M->63M(64M) 860.462ms [117.369s][info][gc] Failed to allocate TLAB, 3096B [117.369s][info][gc] Cancelling GC: Allocation Failure [117.370s][info][gc] Trigger: Handle Allocation Failure [117.710s][info][gc] GC(169) Cancelling GC: Allocation Failure During Evacuation [117.712s][info][gc] GC(169) Cannot finish degeneration, upgrading to Full GC [118.212s][info][gc] GC(169) Pause Degenerated GC (Outside of Cycle) 63M->63M(64M) 842.008ms [118.212s][info][gc] Failed to allocate Shared, 24B [118.212s][info][gc] Cancelling GC: Allocation Failure [118.214s][info][gc] Trigger: Handle Allocation Failure [118.513s][info][gc] GC(170) Cancelling GC: Allocation Failure During Evacuation [118.515s][info][gc] GC(170) Cannot finish degeneration, upgrading to Full GC [118.976s][info][gc] GC(170) Pause Degenerated GC (Outside of Cycle) 63M->63M(64M) 762.032ms ... ``` Please don't backport until this is fully fixed.
12-09-2023
[jdk21u-fix-request] Approval Request from William Kemper Backport is clean. Fixes an issue that may prevent Shenandoah from raising an OOME when expected.
08-09-2023
A pull request was submitted for review. URL: https://git.openjdk.org/jdk21u/pull/147 Date: 2023-09-08 18:15:09 +0000
08-09-2023
[jdk17u-fix-request] Approval Request from William Kemper Unclean backport, but trivial `nullptr`/`NULL` conflict. Passed GHA, also Dacapo, SpecJBB, Extremem and Heapothesys.
08-09-2023
A pull request was submitted for review. URL: https://git.openjdk.org/jdk17u-dev/pull/1724 Date: 2023-09-07 22:43:46 +0000
07-09-2023
Changeset: 716201c7 Author: William Kemper <wkemper@openjdk.org> Committer: Y. Srinivas Ramakrishna <ysr@openjdk.org> Date: 2023-09-07 21:14:28 +0000 URL: https://git.openjdk.org/jdk/commit/716201c77d160dc78db61957aa002eef71641688
07-09-2023
A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/15500 Date: 2023-08-30 23:33:57 +0000
30-08-2023