JDK-8328744 : Parallel: Parallel GC throws OOM before heap is fully expanded
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 17,21,22,23
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2024-03-21
  • Updated: 2025-07-25
  • Resolved: 2025-07-25
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 JDK 23
21.0.4Fixed 22.0.2Fixed 23 b16Fixed
Related Reports
Relates :  
Relates :  
Relates :  
Sub Tasks
JDK-8338920 :  
Description
Run attached test case with following command line:
-Xmx2G  -XX:+UseParallelGC -XX:NativeMemoryTracking=summary -XX:+UnlockDiagnosticVMOptions -XX:+PrintNMTStatistics gc

After test is terminated with OOM, NMT statistics shows:

-                 Java Heap (reserved=2147483648, committed=1541406720)
                            (mmap: reserved=2147483648, committed=1541406720, peak=2147483648) 
 

The heap has not yet fully expanded.


Comments
Reopening the bug to fix the Verification status
25-07-2025

To prevent potential confusion, I’d like to clarify the following: This **premature OOM** can occur *only if* `UseGCOverheadLimit` is enabled (which is the default). The corresponding patch modifies the heuristic that decides whether a young GC should be proactively upgraded to a full GC, based on the **predicted promotion size** and **available space** in the old generation. Before this fix, the heuristic could be overly conservative, especially in scenarios where the heap is nearly full. In such cases, multiple back-to-back full GCs could occur, quickly triggering the **GC overhead limit** and resulting in an **OOM** -- even though the heap had not yet been fully expanded. However, this premature OOM is considered *working as expected*, since the GC overhead limit was indeed exceeded. The patch adjusts the heuristic to be less conservative. As a result, it favors continuing with **young GC** and avoids the previously common overly aggressive back-to-back **full GCs**. (Of course, if the heap is truly too full, back-to-back full GCs may still occur.) If `UseGCOverheadLimit` is **disabled**, we should not see such premature OOMs, because the allocation path will always attempt to **expand the old generation** before giving up. For example, in JDK 21: https://github.com/openjdk/jdk/blob/jdk-21-ga/src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp `ParallelScavengeHeap::failed_mem_allocate` attempts to expand the old generation before returning `null`.
23-07-2025

A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk17u-dev/pull/2515 Date: 2024-05-31 20:07:03 +0000
09-07-2024

[~zgu] Some perf regression on mac-aarch64: https://bugs.openjdk.org/browse/JDK-8332485 Can you reproduce locally?
21-05-2024

[~zgu] just fyi: https://bugs.openjdk.org/browse/JDK-8332225
17-05-2024

Fix request (21u) I would to backport this patch to jdk21u, as it is a p2 bug. It is a clean backport after JDK-8319713 backport.
30-04-2024

A pull request was submitted for review. URL: https://git.openjdk.org/jdk21u-dev/pull/546 Date: 2024-04-30 14:39:47 +0000
30-04-2024

Fix request (22u) I would like to backport this patch to jdk22u, as it is a p2 bug and it is a clean backport.
15-04-2024

A pull request was submitted for review. URL: https://git.openjdk.org/jdk22u/pull/143 Date: 2024-04-15 14:33:04 +0000
15-04-2024

Changeset: 142c311e Author: Zhengyu Gu <zgu@openjdk.org> Date: 2024-03-25 13:04:07 +0000 URL: https://git.openjdk.org/jdk/commit/142c311e3b9bd3f00edaa6ba7bcbc9fc285ee9b9
25-03-2024

A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/18463 Date: 2024-03-23 14:10:45 +0000
23-03-2024