JDK-6819085 : G1: use larger and/or user settable region size
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: hs15
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2009-03-18
  • Updated: 2013-09-18
  • Resolved: 2009-09-16
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 6 JDK 7 Other
6u18Fixed 7Fixed hs16Fixed
Related Reports
Relates :  
JDK-6819098 - G1: reduce RSet scanning times
Relates :  
JDK-6819061 - G1: eliminate serial Other times that are proportional to the collection set length
Description
Using the same region size for small 32-bit JVMs, as well as large 64-bit JVMs, might not be appropriate. We should at least set the region size depending on the build (say: smaller for 32-bit client, small for 32-bit server, and larger for 64-bit server, for some definition of smaller, small, and larger). Ideally, we should experiment with how expensive it is to replace the region size constant with a variable which can either be set ergonomically (depending on heap size), as well as be user-settable.
Comments
EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/2c79770d1f6e
25-09-2009
EVALUATION http://hg.openjdk.java.net/hsx/hsx16/master/rev/13520bae93a6
04-09-2009
EVALUATION http://hg.openjdk.java.net/hsx/hsx16/baseline/rev/13520bae93a6
02-09-2009
EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/2c79770d1f6e
02-09-2009
EVALUATION In the change I'll include a very minor change to make the G1YoungGenSize variable a uintx instead of a intx (otherwise, setting the young gen to 2g or over causes incorrect behavior in the 32-bit JVM).
14-08-2009
EVALUATION The performance hit is minimal. And having larger regions is beneficial to many applications. So, settable region size it is.
14-08-2009
EVALUATION It looks as if larger regions have performance advantages, at least in some cases. For a 32GB heap that we tried, increasing the region size from 1MB to 8MB made GC times about twice as fast. This was mainly due to some bottlenecks described in CR 6819061. Still, there seemed to be additional advantages of having larger regions (e.g., shorter RSet scanning times, given that we have to iterate over the CSet regions; and larger regions means fewer CSet regions). Next step is to evaluate how much of a performance hit would be to make the region size user-/GC-settable.
25-03-2009