JDK-8229373 : Reserve more than MaxHeapSize for the heap to fight humongous object fragmentation in G1
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 14
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2019-08-09
  • Updated: 2020-08-06
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
Blocks :  
JDK-8251263 - G1: Only commit actually used space for humongous objects
Relates :  
JDK-8229049 - JEP 363: Remove the Concurrent Mark Sweep (CMS) Garbage Collector
Relates :  
JDK-8202286 - Allocation of old generation of Java heap on alternate memory devices
Relates :  
JDK-8030849 - Investigate high fragmentation/waste in some situations during allocation during GC in G1
Description
One idea to sidestep the humongous object fragmentation issue in G1 could be reserving a multiple of MaxHeapSize for the G1 java heap and make sure that G1 only ever commits MaxHeapsize space.

The feature to allow allocation of the old gen on NV-DIMM in JDK-8202286 implemented a similar scheme.

Azul's Zing also does the same.
Comments
This has the disadvantage of reducing the compressed oops range though.
15-08-2019