JDK-8309349 : Release Note: GCLocker Induced Garbage Collections No Longer Starve Mutator Threads in G1
  • Type: Sub-task
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 22
  • Priority: P4
  • Status: Resolved
  • Resolution: Withdrawn
  • Submitted: 2023-06-02
  • Updated: 2024-01-29
  • Resolved: 2024-01-29
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 22
22Resolved
Description
Previously, application threads waiting for memory while the heap is locked by GCLocker may be starved from receiving memory by unfortunate thread scheduling. This can cause unnecessary Out-Of-Memory exceptions in the affected threads.

This problem is as follows:

1. Thread A tries to allocate memory as normal, starting a garbage collection. Since GCLocker is active, the thread gets stalled waiting for the garbage collection.
2. The garbage collection pause induced by GCLocker executes and frees some memory.
3. Due to thread scheduling, thread A does not get any of that memory, only other threads also requesting memory at the same time.
4. Steps 1-3 repeat until the retry count threshold has been reached, causing thread A to throw an Out Of Memory exception.

Now, the garbage collection pause in step 2 above tries to satisfy all pending threads' memory requests at once, which completely avoids this situation.

At this time, only G1 has this enhancement. Other collectors may still be prone to this issue.
Comments
Release note tasks must end in either a status of Resolved -> Delivered or Resolved -> Withdrawn.
29-01-2024

Associated Enhancement was closed as won't fix, so closing this too.
17-01-2024