CRR (XXS): 7146246: G1: expose some of the -XX flags that drive which old regions to collect during mixed GCs

Tony Printezis tony.printezis at oracle.com
Wed Mar 21 16:56:39 UTC 2012


Jesper,

Inline.

On 03/21/2012 12:25 PM, Jesper Wilhelmsson wrote:
> Tony,
>
> You also changed the default value of 
> G1OldCSetRegionLiveThresholdPercent from 95% to 90%. Was this 
> intentional?

Actually, yes. And I forgot to document it. Thanks for pointing this 
out. In some of the logs that Charlie showed me there were a lot of 
regions with more than 90% live objects that we were considering for 
collection during mixed GCs. I thought I'd try to exclude them.

> I interpret the explanation of G1HeapWastePercent as if it is 5% in 
> total over all regions. Is that correct?

Yes.

> I thought that was checked on a per region basis.

G1OldCSetRegionLiveThresholdPercent is per-region (so basically, if a 
region has more live objects than that, it's not added to the CSet 
chooser at all).

G1HeapWastePercent determines when we should stop mixed GCs, given that 
even if we do another one we won't get back that much.

Tony

>
>
> On 03/21/2012 04:13 PM, Tony Printezis wrote:
>> Hi all,
>>
>> Can I have a couple of quick code review for this very small change?
>>
>> http://cr.openjdk.java.net/~tonyp/7146246/webrev.0/
>>
>> It turns the following two cmd line params into product params:
>>
>> G1HeapWastePercent (previously called: G1OldReclaimableThresholdPercent)
>> G1MixedGCCountTarget (previous called: G1MaxMixedGCNum)
>>
>> These are helpful in allowing the user to fine-tune G1's behavior wrt 
>> which
>> old regions to collect during mixed GCs, how many mixed GCs to do, etc.
>>
>> I also increased the default value of the former from 1% to 5%. 
>> Charlie ran
>> some performance tests and found that the new default eliminated some 
>> very
>> long mixed GCs that he was experiencing with the old default.
>>
>> Tony
>>



More information about the hotspot-gc-dev mailing list