JDK-7005234 : G1: Artificially reduce the TLAB size when expanding the eden due to the GC locker
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: hs20
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: generic
  • CPU: generic
  • Submitted: 2010-12-07
  • Updated: 2024-02-23
  • Resolved: 2024-02-23
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
tbdResolved
Related Reports
Duplicate :  
Relates :  
Description
In G1, when we are unable to do an evacuation pause because the GC locker is active, we expand the eden to ensure mutator threads can still allocate (see 6994056: G1: when GC locker is active, extend the Eden instead of allocating into the old gen). Typically, we expect to have to expand the Eden by one region, maybe two, since we are expecting the GC locker critical sections to be most of the time short.

Ramki made a good point that, while we're expanding the eden it might be worthwhile to artificially decrease the TLAB size. If the critical section is indeed very short, threads that do allocate TLABs in the expanded eden will probabably allocate only a few objects before the GC locker becomes inactive and we are allowed to do a collection. So, it will not be beneficial to allocate potentially large TLABs most of which will be wasted. In fact, allocating smaller TLABs might allow more threads to be able to allocate out of a smaller number of regions and decrease the eden expansion rate while the GC locker is active.

Comments
JDK-8318706 removed the GCLocker for G1
23-02-2024