Smoother tiered compilation thread ergonomics
Claes Redestad
claes.redestad at oracle.com
Thu Aug 20 14:07:42 UTC 2015
Sure, no code change is needed to experiment (-XX:CICompilerCount=xx) so
I'm already running a few benchmarking experiments to try and evaluate
what we should really aim for in the 8-32 CPU range.
/Claes
On 2015-08-20 02:48, Igor Veresov wrote:
> Claes,
>
> Sure, I agree. Since you seem to be already looking at the problem, could you experiment with smoother functions and check how it affects the startup?
>
> Thanks,
> igor
>
>> On Aug 18, 2015, at 5:02 AM, Claes Redestad <claes.redestad at oracle.com> wrote:
>>
>> Hi,
>>
>> I noticed the thread ergonomics for tiered compilation have a few odd jumps
>> that perhaps could be improved.
>>
>> The calculation used to derive CICompilerCount for Tiered in
>> vm/runtime/advancedThresholdPolicy.cpp:
>>
>> int log_cpu = log2_intptr(os::active_processor_count());
>> int loglog_cpu = log2_intptr(MAX2(log_cpu, 1));
>> count = MAX2(log_cpu * loglog_cpu, 1) * 3 / 2;
>>
>> Seems to evaluate to:
>>
>> #CPUs CICompilerCount
>> <4 2
>> 4 3
>> 8 4
>> 16 12
>> 32 15
>> 64 18
>> 128 21
>> 256 36
>> 512 40
>> 1024 45
>> 2048 49
>>
>> The jump from 4 to 12 threads at 16 processors doesn't look very elegant (there's
>> a small bump going from 128->256, too). It seems reasonable the ratio of compiler
>> threads to actual CPUs should diminish as CPUs increase, but going from 8 (or 15)
>> to 16 actually increases the ratio.
>>
>> If we'd replace log2_intptr with some non-discrete function instead of using
>> log2_intptr, we could smooth out the curve, which I think would be beneficial
>> for the rather common cases where systems have somewhere between 8 and 32 CPUs.
>>
>> /Claes
More information about the hotspot-compiler-dev
mailing list