JDK-8059452 : G1: Change the default values for G1HeapWastePercent and G1MixedGCLiveThresholdPercent
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 8u40,9
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2014-09-30
  • Updated: 2017-04-14
  • Resolved: 2014-09-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.
8u40Fixed 9 b35Fixed
Related Reports
Relates :  
When the flags G1HeapWastePercent and G1MixedGCLiveThresholdPercent were introduced their default values were picked without much performance analysis. 

Recent performance runs indicate that G1HeapWastePercent often benefit from a lower value and that G1MixedGCLiveThresholdPercent benefit from a higher value.

Suggestion is to change the default for G1HeapWastePercent to 5 (used to be 10) and G1MixedGCLiveThresholdPercent to 85 (used to be 65).
Suggestion for release note: "The default value for G1HeapWastePercent has changed from 10 to 5 and the default value for G1MixedGCLiveThresholdPercent has changed from 65 to 85. This has the effect that mixed GCs in G1 will handle a larger part of the heap." It would also be good to a known issue: In hadoop benchmarks such as NoSQL benchmark YCSB on HBase, with storage handled by HDFS, we have seen ScanRS times go up quite a lot when moving to 8u40. This is due to the new default values for G1HeapWastePercent and G1MixedGCLiveThresholdPercent. A work around for this problem is to explicitly set these flags to the old values: -XX:G1HeapWastePercent=10 -XX:+UnlockExperimentalVMOptions -XX:G1MixedGCLiveThresholdPercent=65