-
Enhancement
-
Resolution: Unresolved
-
P4
-
9
Currently G1 will allocate a new PLAB for rather large allocations (up to desired PLAB size - alignment_reserve). See PLABAllocator::allocate_direct_or_new_plab().
CMS allows the same, but objects within ]PLAB size - alignment reserve, PLAB size] fail allocation within a newly allocated PLAB (thus wasting up to ParallelGCBufferWastePct in the existing PLAB) and are directly promoted to old gen, and keeping the new PLAB.
Parallel GC only reallocates a new PLAB if the object is < half of PLAB size. This might be more efficient, as large objects almost completely fill up PLABs anyway, having a larger overhead than just direct allocation because the next allocation will most likely require an immediate PLAB reload.
Investigate the options a little bit more to see what's best.
CMS allows the same, but objects within ]PLAB size - alignment reserve, PLAB size] fail allocation within a newly allocated PLAB (thus wasting up to ParallelGCBufferWastePct in the existing PLAB) and are directly promoted to old gen, and keeping the new PLAB.
Parallel GC only reallocates a new PLAB if the object is < half of PLAB size. This might be more efficient, as large objects almost completely fill up PLABs anyway, having a larger overhead than just direct allocation because the next allocation will most likely require an immediate PLAB reload.
Investigate the options a little bit more to see what's best.
- relates to
-
JDK-8030849 Investigate high fragmentation/waste in some situations during allocation during GC in G1
- Open