EVALUATION

http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/2c79770d1f6e
                                     

EVALUATION

http://hg.openjdk.java.net/hsx/hsx16/master/rev/13520bae93a6
                                     

EVALUATION

http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/2c79770d1f6e
                                     

EVALUATION

http://hg.openjdk.java.net/hsx/hsx16/baseline/rev/13520bae93a6
                                     

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).
                                     

EVALUATION

The performance hit is minimal. And having larger regions is beneficial to many applications. So, settable region size it is.
                                     

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.