counterproductive. The CMS pauses are generally much shorter than a young generation
pause, and a particular application may not be sensitive to those additional pauses—it's a
trade-off between the additional pauses and the reduced chance of a concurrent mode failure.
But continually running the background GC pauses will likely lead to excessive overall
pauses, which will in the end ultimately reduce the performance of the application.
Unless those trade-offs are acceptable, take care not to set the CMSInitiatingOccu-
pancyFraction higher than the amount of live data in the heap, plus at least 10% to 20%.
Adjusting the CMS background threads
Each CMS background thread will consume 100% of a CPU on a machine. If an application
experiences a concurrent mode failure and there are extra CPU cycles available, the number
of those background threads can be increased by setting the -XX:ConcGCThreads= N flag. By
default, that value is set based on the value of the ParallelGCThreads flag:
ConcGCThreads = (3 + ParallelGCThreads) / 4
This calculation is performed using integer arithmetic, which means there will be one Con-
cGCThread for up to four ParallelGCThreads , two ConcGCThreads for between five and
eight ParallelGCThreads , and so on.
The key to tuning this flag is whether there are available CPU cycles. If the number of Con-
cGCThreads is set too high, they will take CPU cycles away from the application threads; in
effect, small pauses will be introduced into the program as the application threads wait for
their chance to run on the CPU.
Alternately, on a system with lots of CPUs, the default value of ConcGCThreads may be too
high. If concurrent mode failures are not occurring, the number of those threads can often be
reduced in order to save CPU cycles.