RFR(XS): 8001425: G1: Change the default values for certain G1 specific flags

[Tao Mao]

Hi,
I don't know these specific performance tunings. I have another concern 
(maybe not that related to the change).

It seems the common practice to store globals is to define them directly 
in share/vm/runtime/globals.hpp although I know there are a lot of other 
global definition files for compilers and platforms. However, within GC 
code, I don't see other GC code does so. Please consider if it is 
motivated enough to move these definitions to globals.hpp in order to 
keep the code lean. Correct me if I've got wrong.

Thanks.
Tao

On 1/9/2013 4:28 PM, John Cuthbertson wrote:
> Hi Everyone,
>
> Can I have a couple of volunteers look of the code changes for this 
> CR? The webrev can be found at: 
> http://cr.openjdk.java.net/~johnc/8001425/webrev.0/
>
> Background:
> These changes change the default values of:
>
> G1MixedGCLiveThresholdPercent from 90 down to 65
> This means that we we don't consider regions with a live occupancy > 
> 65% as good candidates for collection during the next mixed GC phase. 
> Evacuating regions that have a high live occupancy can get expensive 
> and a 90% cut off was deemed to be too high.
>
> G1HeapWastePercent up from 5% to 10%
> This means that we are prepared to sacrifice 10% of the heap to avoid 
> really expensive mixed GCs.
>
> G1MixedGCCountTarget up from 4 to 8
> We can do up to 8 mixed GCs after a marking cycle instead of 4. This 
> should mean that an individual mixed GC is less expensive and we 
> should collect more regions before we reach the regions that are 
> really expensive to collect.
>
> And for heaps no more than 4GB:
>
> G1NewSizePercent is reduced from 20% to 5%. This value was placing a 
> lower bound on how far we could shrink the young generation. 20% was 
> deemed to be too high.
>
> G1MaxNewSizePercent is reduced from 80% to 60%. A value of 80% was 
> allowing the young generation to grow too large increasing the 
> possibility of evacuation failures.
>
> These new values have been suggested by the performance team based 
> upon their tuning experiments (including feedback from people the 
> performance team has helped out).
>
> Going forward I think some of these values should be set dynamically. 
> For example G1MixedGCLiveThresholdPercent could be tied to the overall 
> heap occupancy.
>
> Thanks,
>
> JohnC