JDK-8019902 : G1: Use the average heap size rather than the minimum heap size to calculate the region size
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2013-07-04
  • Updated: 2020-03-27
  • Resolved: 2013-08-30
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 8 Other
8Fixed hs25Fixed
Related Reports
Duplicate :  
JDK-8020599 - G1: VM crashed with OOME on solaris with large heap
Relates :  
JDK-8025564 - gc/memory/UniThread/Linear1 times out during heap verification
Relates :  
JDK-8241670 - Enhance heap region size ergonomics to improve OOTB performance
Relates :  
JDK-8020599 - G1: VM crashed with OOME on solaris with large heap
Description
When G1 decides on the heap region size it aims for 2048 regions for the heap size. But the heap size it is using is the minimum heap size that Arguments::min_heap_size() picks.

This size is normally very small. If you set -Xms on the command line this value will be used, but otherwise the value is OldSize + NewSize, which defaults to about 6MB.

This means that HeapRegion::setup_heap_region_size() will almost always come up with a G1 region size of 1MB since this is the minimum region size.

In performance testing we have seen improvements with larger heap regions. Larger heap regions also lead to fewer regions which lead to less memory footprint overhead as we have fixed memory costs for each region.

A more reasonable calculation would be to use the average heap size to determine the region size.