JDK-8258088 : Improve G1 PLAB allocator pathological case where it keeps doing direct allocations
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 16,17
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2020-12-11
  • Updated: 2023-08-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.
Other
tbdUnresolved
Related Reports
Relates :  
Relates :  
Relates :  
Description
In the slow path for PLAB allocation G1 needs to determine whether it should discard the current PLAB buffer to allocate an object or do direct allocation.

To keep the waste percentage goal of 10% (i.e. ParallelGCBufferWastePct) it always directly allocates objects that are larger than ParallelGCBufferWastePct percent of the current PLAB size.

This works to keep this goal, but raises one question and one issue:
- wouldn't it be more direct to check for whether the remaining PLAB space is < 10% of PLAB size? (I think the checks are equivalent in this case; document this!)
- there can be a pathological case (which the test/hotspot/jtreg/gc/g1/plab/TestPLABPromotion.java test exercises) where if the application only has allocations larger than that threshold, no PLAB allocation will be done after some point - which is slow.

There should be some dynamic change (increase) of that threshold based on failures.

This heuristic has been in G1 since initial import.