Better default for ParallelGCThreads and ConcGCThreads by using number of physical cores and CPU mask.
jon.masamitsu at oracle.com
Fri Nov 22 17:48:31 UTC 2013
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
> 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
it be left in. Make it an experimental flag to make it easier to remove
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") \
We do have the ParallelGCThreads flag to workaround regressions but
know what value is currently set by the ergonomics so won't know what value
to use for ParallelGCThreads to workaround a regression.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the hotspot-gc-dev