The number of compiler threads (for all three compiler options) can be adjusted by setting
the -XX:CICompilerCount= N flag (with a default value given in the previous table). That is
the total number of threads the JVM will use to process the queue(s); for tiered compilation,
one-third of them (but at least one) will be used to process the client compiler queue, and the
remaining threads (and also at least one) will be used to process the server compiler queue.
When might you consider adjusting this value? If a program is run on a single-CPU system,
then having only one compiler thread might be slightly beneficial: there is limited CPU
available, and having fewer threads contending for that resource will help performance in
many circumstances. However, that advantage is limited only to the initial warm-up period;
after that, the number of eligible methods to be compiled won't really cause contention for
the CPU. When the stock batching application was run on a single-CPU machine and the
number of compiler threads was limited to one, the initial calculations were about 10% faster
(since they didn't have to compete for CPU as often). The more iterations that were run, the
smaller the overall effect of that initial benefit, until all hot methods were compiled and the
benefit was eliminated.
When tiered compilation is used, the number of threads can easily overwhelm the system,
particularly if multiple JVMs are run at once (each of which will start many compilation
threads). Reducing the number of threads in that case can help overall throughput (though
again with the possible cost that the warm-up period will last longer).
Similarly, if lots of extra CPU cycles are available, then theoretically the program will bene-
fit—at least during its warm-up period—when the number of compiler threads is increased.
In real life, that benefit is extremely hard to come by. Further, if all that excess CPU is avail-
able, you're much better off trying something that takes advantage of the available CPU
cycles during the entire execution of the application (rather than just compiling faster at the
One other setting that applies to the compilation threads is the value of the -
XX:+BackgroundCompilation flag, which by default is true . That setting means that the
queue is processed asynchronously as just described. But that flag can be set to false , in
which case when a method is eligible for compilation, code that wants to execute it will wait
until it is in fact compiled (rather than continuing to execute in the interpreter). Background
compilation is also disabled when -Xbatch is specified.