JDK-8357684 : Release Note: No More OutOfMemoryErrors due to JNI in Serial/Parallel GC
  • Type: Sub-task
  • Component: hotspot
  • Sub-Component: gc
  • Priority: P4
  • Status: Closed
  • Resolution: Delivered
  • Submitted: 2025-05-24
  • Updated: 2025-05-26
  • Resolved: 2025-05-26
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 25
25Resolved
Description
Serial and Parallel garbage collectors now ensure that no Java threads are in a JNI critical region before initiating a garbage collection eliminating unnecessary `OutOfMemoryError`s.

Previously, garbage collection could early-return without reclaiming any memory if any thread remained in such a region. This could lead to unexpected `OutOfMemoryError`s (OOMEs), as garbage collection might not have had a chance to reclaim memory even after a few retries. Increasing `GCLockerRetryAllocationCount` has often been suggested as a workaround for avoiding this kind of premature OOME.

With this change, a pending garbage collection request will wait for all Java threads to exit JNI critical regions and block new entries. This guarantees that once inside the safepoint, no threads remain in critical regions and garbage collection can always proceed to completion. As a result, the diagnostic flag `GCLockerRetryAllocationCount` has been removed, as it is no longer necessary.
Comments
lgtm
26-05-2025