Description
The heap reserve is a portion of the heap that is set aside to cope with “emergency situations”, like when ZGC needs to compact the heap when it’s already full. However, due to a number of factors (mutator relocation, page pinning, etc) there is no guarantee that relocation will always succeed. In fact, we can end up in situations where we fail to reclaim memory even when 90% of the heap is garbage (JDK-8254346 is an example of where this happens).
So, even if the heap reserve serves its purpose well on most cases, it still doesn't offer any guarantees that relocation succeeds in all cases. To get the guarantees we want we could, instead of having a heap reserve, turn to doing in-place relocation. In other words, if a worker fails to allocate a new page, then it compacts the page currently being relocated, and then use that page as the target for new allocations. In addition, if a mutator fails to relocate an object, then it waits for a worker to relocate the object, instead of pinning the page.
So, even if the heap reserve serves its purpose well on most cases, it still doesn't offer any guarantees that relocation succeeds in all cases. To get the guarantees we want we could, instead of having a heap reserve, turn to doing in-place relocation. In other words, if a worker fails to allocate a new page, then it compacts the page currently being relocated, and then use that page as the target for new allocations. In addition, if a mutator fails to relocate an object, then it waits for a worker to relocate the object, instead of pinning the page.
Attachments
Issue Links
- relates to
-
JDK-8254346 ZGC runs out of memory with appcds GCDuringDump.java on linux/aarch64
- Resolved
-
JDK-8271121 ZGC: stack overflow (segv) when -Xlog:gc+start=debug
- Closed