RFR(XS): 8001425: G1: Change the default values for certain G1 specific flags
bengt.rutisson at oracle.com
Thu Jan 10 10:07:20 UTC 2013
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.
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:
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 :)
On 1/10/13 1:28 AM, 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:
> 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.
More information about the hotspot-gc-dev