Java Reference
In-Depth Information
CMS collector experiences concurrent mode failures as well. In this example, the CMS back-
ground processing was sufficient to keep up with the demands of the application.
These are the sort of trade-offs to consider when deciding which GC algorithm suits your
performance goals. If the average time is all you care about, then the throughput collector
will likely look similar to a concurrent collector, and you can consider the CPU usage instead
(in which case, the throughput collector will be the better choice). If you're interested in the
90th% or other percentile-based response times, then only testing can see where those line up
with the number of full GC cycles the application needs to perform its job.
1. When measuring response time or throughput, the choice between throughput and
concurrent collectors is dependent on the amount of CPU available for the back-
ground concurrent threads to run.
2. The throughput collector will frequently have a lower average response time than
a concurrent collector, but the concurrent collector will often have a lower 90th%
or 99th% response time.
3. When the throughput collector performs excessive full GCs, a concurrent collect-
or will often have lower average response times.
Choosing between CMS and G1
The tests in the last section used CMS as the concurrent collector. As a basic rule of thumb,
CMS is expected to outperform G1 for heaps that are smaller than 4 GB. CMS is a simpler
algorithm than G1, and so in simple cases (i.e., those with small heaps), it is likely to be
faster. When large heaps are used, G1 will usually be better than CMS because of the manner
in which it can divide work.
CMS background thread(s) must scan the entire old generation before any objects can be
freed. The time to scan the heap is obviously dependent on the size of the heap. If the CMS
background thread does not finish scanning the heap and freeing objects before the heap fills
up, CMS will experience a concurrent mode failure: at that point, CMS has to revert to doing
a full GC with all application threads stopped. That full GC is done only with a single thread,
making it a very severe performance penalty. CMS can be tuned to utilize multiple back-
ground threads to minimize that change, but the larger the heap grows, the more work those
Search WWH ::

Custom Search