RFR(S): 8198756: Limit number of compiler threads for small code cache

[Vladimir Kozlov]

Hi Doerr,

The problem with your proposal is that we don't use scale number of compiler threads when we have a lot of cpus (>1000 
on big "slow" machines).
By default for tiered compilation we have 240Mb for CodeCache. With your formula we always will have 7 threads (2 C1 and 
5 C2) which could be fine if machine has < total 32 procs/threads. But for big machines it may be bottleneck for JIT 
compilation intensive applications (and for startup when most JIT compilations happened).

Main motivation of current approach was to reach peak performance (c2 compilations) as fast as possible. What we usually 
observed before is large compilation queue for C2 compilation because slow throughput of C2. It was especially visible 
with tiered compilation when compilation thresholds reached faster with first tier compiled profiling code.

And I agree that we may have problem with number of compiler threads at the beginning of graph (< 32 cpu threads) when 
the number grows too fast:

Graph for3*​log2(​x)*​log2(​log2(​x))/​2
-60-55-50-45-40-35-30-25-20-15-10-55101520253035404550556065707580859095100105110115120125130-35-30-25-20-15-10-55101520253035404550556065x: 
32.0711217y: 17.4325495


May be we should have a formula which takes into account code cache size and number of cpu threads.

Igor Veresov was original developer of current formula. It would be nice to hear his opinion.

Thanks,
Vladimir

On 2/27/18 8:10 AM, Doerr, Martin wrote:
>
> Hi,
>
> the VM currently starts a large amount of compiler threads on systems with many CPUs regardless of the code cache size.
>
> This doesn't make sense for very small code cache sizes.
>
> The dynamically determined number of compiler threads can be observed by:
>
> jdk/bin/java -XX:ReservedCodeCacheSize=128m -XX:+PrintFlagsFinal -version|grep CICompiler
>
> I suggest not to use more than 1 compiler thread per 32MB of code cache:
>
> http://cr.openjdk.java.net/~mdoerr/8198756_CompilerCount/webrev.00/ 
> <http://cr.openjdk.java.net/%7Emdoerr/8198756_CompilerCount/webrev.00/>
>
> This seems to be conservative.
>
> Please review and let me know if you have a different limitation proposal.
>
> Best regards,
>
> Martin
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20180227/0e057b05/attachment-0001.html>