-
Sub-task
-
Resolution: Delivered
-
P4
-
25
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.
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.