JDK-8191471 : Elastic TLABs for G1
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 9
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2017-11-17
  • Updated: 2018-07-02
  • Resolved: 2018-05-02
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.
JDK 11
11 b12Fixed
Related Reports
Relates :  
JDK-8205722 - 6.6% regression in SPECjvm2008-MonteCarlo with G1 on Linux in JDK 11
Relates :  
JDK-8202662 - JFR tests fails: Could not find leak with class
Description
G1 may waste a serious amount of space during TLAB allocation because of the many region boundaries.

I.e. since the TLAB size is fixed, G1 will, if TLAB size grows large waste a lot of space at the end of every region, because although the current allocation might fit, the TLAB may not.

This may waste up to 50% of available memory, causing performance issues.

Implement elastic TLABs like G1 already does for PLABs.
Comments
I've been looking into this area the last week and G1 do have elastic TLABs in the sense that we check how much is remaining of the region and request size based on that. The problem is that there is a race to get this amount of memory and there are cases where we do waste a lot of memory.
18-04-2018
This should be fairly non-intrusive because all TLAB handling in G1 is done in VM code (g1 does not support FastTLABRefill, and that one seems to be on its way out)
17-11-2017