JDK-7113021 : G1: automatically enable young gen size auto-tuning when -Xms==-Xmx
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: hs23
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2011-11-17
  • Updated: 2013-09-18
  • Resolved: 2012-03-29
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 7 JDK 8 Other
7u4Fixed 8Fixed hs23Fixed
Related Reports
Relates :  
Description
Currently, we enable young gen size auto-tuning when min young gen size != max young gen size (see 6929868: G1: introduce min / max young gen size bounds). However, if -Xms is set to the same value as -Xmx and the user does not set NewSize and MaxNewSize explicitly, the min and max young gen size are calculated to be the same value (we use the NewRatio calculation by default). So in this case young gen size auto-tuning is turned off by default. We should make sure it is enabled by default by coming up with reasonable min / max young gen size defaults. Additionally, we should also apply said defaults in the case where -Xms != -Xmx instead of just applying NewRatio to the min / max heap size.
There are three command line options related to the young gen size: NewSize, MaxNewSize and NewRatio (There is also -Xmn, but that is just a short form for NewSize==MaxNewSize). G1 will use its internal heuristics to calculate the actual young gen size, so these options basically only limit the range within which G1 can pick a young gen size. Also, these are general options taking byte sizes. G1 will internally work with a number of regions instead. So, some rounding will occur.

The idea is that my fix should work pretty much as follows:

If nothing related to the the young gen size is set on the command line we should allow the young gen to be between 20% and 50% of the heap size. This means that every time the heap size changes the limits for the young gen size will be updated.

If only -XX:NewSize is set we should use the specified value as the minimum size for young gen. Still using 50% of the heap as maximum.

If only -XX:MaxNewSize is set we should use the specified value as the maximum size for young gen. Still using 20% of the heap as minimum.

If -XX:NewSize and -XX:MaxNewSize are both specified we use these values. No updates when the heap size changes. There is a special case when NewSize==MaxNewSize. This is interpreted as "fixed" and will use a different heuristic for calculating the collection set when we do mixed collection.

If only -XX:NewRatio is set we should use the specified ratio of the heap as both min and max. This will be interpreted as "fixed" just like the NewSize==MaxNewSize case above. But we will update the min and max everytime the heap size changes.

NewSize and MaxNewSize override NewRatio. So, NewRatio is ignored if it is combined with either NewSize or MaxNewSize. (A warning message is printed.)

Comments
EVALUATION http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/1cbe7978b021
22-03-2012

EVALUATION http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/1cbe7978b021
22-12-2011