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

[Kirk Pepperdine]

Hi Charlie,

In this case I would have to say that having more frequent GCs that succeed is much better than evacuation failures. Also having different values for different heap sizes is really confusing. Is it really necessary to have different percentages for different heap sizes and is so is there a known gradient for correlating the size vs percent?

As an aside, I had fun this week playing with G1 for a desktop app that did some things with video that makes it exceptionally pause time sensitive. Video processing of this nature gives some very very steady object allocation rates which does simplify the tuning process.

I decided to try G1 because I couldn't get a generational Eden to be as small as I needed to ensure frequent enough young gen collections while maintaining large enough survivor spaces to capture short lived objects. There was another issue in that the deployment environment didn't leave me feeling wonderful about deploying a right sized (small) heap. What I was looking to do was deploy with a large heap that behaved right sized in order to avoid possible OOMEs. The box has 24 cores and this is a perfect case for iCMS as the larger heap caused pause times to creep up until a CMS cycle was triggered.. this doesn't happen with iCMS but since it's been (or about to be) deprecated.... Anyways, in starting with default values G1 young size fell to a value that was about 4x the desired young gen size in CMS which resulted in too infrequent collections and missed pause time goals. This is were things ended for the moment. I'm going to force young gen to be smaller but I'm also observing that tenured collections are not happening frequently enough and that again appears to destabilize pause times for young gen collections. Do you have any advice on how one might best increase the frequency of tenured space marking?

Regards,
Kirk


On 2013-01-11, at 2:32 PM, Charlie Hunt <chunt at salesforce.com> wrote:

> Hi John,
> 
> Fwiw, I'm fine with Bengt's suggestion of having G1NewSizePercent the same for all Java heap sizes.
> 
> 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?
> 
> I'd be interested in hearing your thoughts along with Monica's, Jon Masa, John Coomes and Ramki, if they have time of course.
> 
> hths,
> 
> charlie ...
> 
> On Jan 10, 2013, at 12:47 PM, John Cuthbertson wrote:
> 
>> Hi Bengt,
>> 
>> Thanks for reviewing the code. Replies inline...
>> 
>> On 1/10/2013 2:07 AM, Bengt Rutisson wrote:
>>> 
>>> Hi John,
>>> 
>>> Changes look good.
>>> 
>>> One question about G1NewSizePercent and G1MaxNewSizePercent. Why are 
>>> these only changed for heap sizes below 4GB? I would think that at 
>>> least the reduction of G1NewSizePercent would be even more important 
>>> for larger heap sizes. If we want to get lower pause times on larger 
>>> heaps we need to be able to have a small young gen size.
>> 
>> The simple answer is: it was suggested by Monica and Charlie. Personally 
>> I'm OK with making the new values of G1NewSizePercent and 
>> G1MaxNewSizePercent the defaults for all heap sizes and we might (or 
>> most likely will) go there in the future - but for the moment we're 
>> being conservative.
>> 
>> As I mentioned we would like to make G1 a bit more adaptive - and both 
>> Monica and Charlie have some ideas in that area.
>> 
>>> 
>>> Also, your change in arguments.cpp is guarded by #ifndef SERIALGC. 
>>> This is correct of course, but Joe Provino has a change out that will 
>>> replace this kind of check with #if INCLUDE_ALL_GCS:
>>> 
>>> http://cr.openjdk.java.net/~jprovino/8005915/webrev.00
>>> 
>>> Neither you nor Joe will get any merge conflicts if your changes are 
>>> both pushed. It will even still compile. But the code inside #ifndef 
>>> SERIALGC will never be executed. So, it might be good to keep any eye 
>>> out for how Joe's change propagate through the repositories to make 
>>> sure that you can manually resolve this.
>>> 
>>> My guess is that Joe's change will have to wait a while since it 
>>> includes make file changes that potentially interfere with changes for 
>>> the new build system. So, hopefully you get to push this first :)
>> 
>> Thanks. I've been watching the progress that Joe's change has been 
>> making. I guess you can think of this change as the one for hs24 and 
>> another with the SERIALGC changed appropriately being for hs25. :)
>> 
>> Thanks,
>> 
>> JohnC
>> 
>