RFR(XS): 8001425: G1: Change the default values for certain G1 specific flags
john.cuthbertson at oracle.com
Wed Jan 16 18:17:58 UTC 2013
If there were a truly compelling reason then I would defend change and
*try* to explain the reason. In this case it was just conservatism -
changing the defaults of flags that can really alter behavior always
makes me slightly nervous. :)
What do you mean by an incremental mode for G1? Anything you can cite?
On 1/16/2013 12:09 AM, Kirk Pepperdine wrote:
> Hi John,
> You know, there might be a good reason to have different values for different heap sizes.. some thing that makes sense when you look at the implementation. If so, that might justify the need to do this. I just don't understand *why*? But maybe that's just me. I'm not responsible for the implementation, I just help people deal with what's on the table and so unless something seem really not right, like dropping incremental modes, I'll pass comment and then shutup to let you get on with it... ;-)
> BTW, not to stir up any trouble but it would be nice to have a incremental mode for G1 for machines with large number of cores.
> On 2013-01-15, at 9:42 AM, John Cuthbertson <john.cuthbertson at oracle.com> wrote:
>> Hi Kirk,
>> I know you haven't responded to me directly but I did your email with interest and cited it in my reply to Charlie Hunt.
>> On 1/12/2013 4:39 AM, Kirk Pepperdine wrote:
>>> 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?
>> Unless I hear any objections, I'll apply the new young gen bounds to all heap sizes.
More information about the hotspot-gc-dev