Better default for ParallelGCThreads and ConcGCThreads by using number of physical cores and CPU mask.

[Jon Masamitsu]

On 11/22/2013 4:33 AM, Bengt Rutisson wrote:
>
>
>>
>>     Do we need the flag AdjustGCThreadsToCores? It seems like this is
>>     a good change and it is always nice to reduce the number of flags
>>     we have. If you feel unsure about the change it may be good to be
>>     able to disable it, but in general I think it would be better to
>>     decide that this is the default behavior and go with it.
>>
>>
>> I have no strong opinion. If you guys can confirm the improvements 
>> and feel like you don't need the flag, that would be ideal.
>
> Yes, this is an interesting dilemma. Personally I don't think I have 
> the cycles right now to do any performance testing of this fix. But I 
> assume that you don't have access to enough machines and benchmarks to 
> test this properly on all supported platforms. I'll bring this up 
> internally to see if there is any process for handling this type of 
> situation...
>
> Since your change is for Linux only and you have done the measurements 
> there, I'm fine with your results. I would prefer skipping the 
> AdjustGCThreadsToCores flag based on the data you provided. Especially 
> since we can still set ParallelGCThreads explicitly on the command 
> line if we need to work around a regression somewhere.

I fully expect to need the AdjustGCThreadsToCores flag on Sparc so I 
would prefer
it be left in.  Make it an experimental flag to make it easier to remove 
later

1405experimental(bool, AdjustGCThreadsToCores, true,                               \
1406           "Create GC worker threads with respect to the number of physical "\
1407           "cores available from the CPU mask. Ignores hardware threads")    \
1408


We do have the ParallelGCThreads flag to workaround regressions but 
users don't
know what value is currently set by the ergonomics so won't know what value
to use for ParallelGCThreads to workaround a regression.

Jon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20131122/d25caf24/attachment.htm>