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

John Cuthbertson john.cuthbertson at oracle.com
Tue Jan 15 17:40:18 UTC 2013

Hi Charlie

Thanks for looking over the changes. Replies inline....

On 1/11/2013 11:32 AM, Charlie Hunt wrote:
> Hi John,
> Fwiw, I'm fine with Bengt's suggestion of having G1NewSizePercent the same for all Java heap sizes.

I don't have a problem with this. By applying it heaps > 4GB , I was 
just being conservative.

> I'm on the fence with whether to do the same with G1MaxNewSizePercent.  For me I find the MaxNewSizePercent a bit tricky than NewSizePercent.  WIth NewSizePercent, if young gen is sized "too small", I think the worst case is we have some GCs that are well below the pause time target.  But, with MaxNewSizePercent, if it's allowed to get "too big", then the worst case is evacuation failures.
> So, if you did move MaxNewSizePercent down to 60, we'd have a situation where we'd be less likely to have evacuation failures.  Perhaps it's ok to apply this change to all Java heap sizes too?

Again I don't have a problem with applying the new value to all heap 
sizes but I am a little concerned about the implications. The benefit is 
definitely less risk of evacuation failures but the it could also

* increase the number of young GCs:
     ** increasing the GC overhead and increasing the heap slightly more 
     ** lowering throughput
* slightly increase the amount that gets promoted
     ** triggering marking cycles earlier and more often (increased SATB 
barrier overhead)
     ** more cards to be refined (we only refine cards in old regions) 
increasing the write barrier costs and the RS updating phase of the pauses,
     ** increases the importance of "taming the mixed GCs".

 From Kirk's email it sounds like this is a trade off people are 
prepared to live with.

Unless I hear any objections, I'll apply the new young gen bounds to all 
heap sizes.


More information about the hotspot-gc-dev mailing list