-
Sub-task
-
Resolution: Withdrawn
-
P4
-
22
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.
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.