JDK-8251288 : G1: Young gen sizing should take short-living humongous object allocation into account
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 16
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • Submitted: 2020-08-07
  • Updated: 2021-09-02
  • Resolved: 2021-09-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.
Other
tbdResolved
Related Reports
Duplicate :  
Relates :  
Relates :  
Description
Attached is an example program (from JDK-8248783) that allocates a lot of short-living humongous objects.

After startup a significant part of allocations are short-living humongous objects, i.e. objects that are quickly discarded as they are used e.g. for (web request) output buffers. Eager reclamation will reclaim them.

However they do cause evacuation failures or worse. JDK-8248783 tried to fix this by adding young collections at some point.

An alternative change that handles this application better could be G1 taking this short-living humongous object allocation into account in its eden sizing. These object are following the weak generational hypothesis, and treating them as such would help the situation.

Something like increasing the frequency of gc (i.e. decreasing young gen) when close to using up all memory (causing evacuation failure) to more frequently reclaim those.

Directly accounting them (their size) as young gen objects (all the time) may decrease performance too much.

Also note that potentially making evacuation failure more clever wrt to in which generation to place failed regions might be an alternative, preferable solution (e.g. JDK-8140326)
Comments
JDK-8257774 introduces additional "preventive" minor garbage collections similar to what the results of this change would have been. So I am closing this issue as a duplicate of the other. If there are still use cases that this does not cover, please open a new issue. A version of the provided test case which has the mentioned C2 optimization mentioned in JDK-8248783 circumvented does not do full collections at least.
02-09-2021