-
Enhancement
-
Resolution: Fixed
-
P4
-
8, 9
-
b81
-
generic
-
generic
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8141882 | emb-9 | Thomas Schatzl | P4 | Resolved | Fixed | team |
If an evacuation failure is seen during object copying, we still have to proceed with the scanning of the remaining roots and RSets. Objects for which we fail to allocate space are self-forwarded (i.e. they are forwarded to themselves). This means that for many, many object copies we are going to execute the allocation path (attempting to to allocate a PLAB, and hence attempting to allocate a new GC alloc region) many, many times. Most (if not all) of these allocation attempts (of GC alloc regions) are doomed to failure.
We should be able to reduce the time of pauses that see an evacuation failure if we reduce the number of times we execute the slow path when an evacuation failure is seen.
We should be able to reduce the time of pauses that see an evacuation failure if we reduce the number of times we execute the slow path when an evacuation failure is seen.
- backported by
-
JDK-8141882 G1: Reduce unnecessary (and failing) allocation attempts when handling an evacuation failure
-
- Resolved
-
- relates to
-
JDK-8271884 G1CH::_expand_heap_after_alloc_failure is no longer needed
-
- Resolved
-
-
JDK-8004687 G1: Parallelize object self-forwarding and scanning during an evacuation failure
-
- Resolved
-