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

Igor Veresov igor.veresov at oracle.com
Thu Mar 1 07:05:21 UTC 2018


I’m curious about the rationale for tying the number of thread to the size of the code cache. Is it because you don’t want them to keep holding the space for their code buffers when they are idle?

igor

> On Feb 27, 2018, at 10:19 AM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
> 
> 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 for 3*​log2(​x)*​log2(​log2(​x))/​2
> -60
> -55
> -50
> -45
> -40
> -35
> -30
> -25
> -20
> -15
> -10
> -5
> 5
> 10
> 15
> 20
> 25
> 30
> 35
> 40
> 45
> 50
> 55
> 60
> 65
> 70
> 75
> 80
> 85
> 90
> 95
> 100
> 105
> 110
> 115
> 120
> 125
> 130
> -35
> -30
> -25
> -20
> -15
> -10
> -5
> 5
> 10
> 15
> 20
> 25
> 30
> 35
> 40
> 45
> 50
> 55
> 60
> 65
> x: 32.0711217
> y: 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/20180228/6b41f30f/attachment-0001.html>


More information about the hotspot-compiler-dev mailing list