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