1. CMS has several GC operations, but the expected operations are minor GCs and
2. Concurrent mode failures and promotion failures in CMS are quite expensive;
CMS should be tuned to avoid these as much as possible.
3. By default, CMS does not collect permgen.
Tuning to Solve Concurrent Mode Failures
The primary concern when tuning CMS is to make sure that there are no concurrent mode or
promotion failures. As the CMS GC log showed, a concurrent mode failure occurs because
CMS did not clean out the old generation fast enough: when it comes time to perform a col-
lection in the young generation, CMS calculates that it doesn't have enough room to promote
those objects to the old generation and instead collects the old generation first.
The old generation initially fills up by placing the objects right next to each other. When
some amount of the old generation is filled (by default, 70%), the concurrent cycle begins
and the background CMS thread(s) start scanning the old generation for garbage. At this
point, a race is on: CMS must complete scanning the old generation and freeing objects be-
fore the remainder (30%) of the old generation fills up. If the concurrent cycle loses the race,
CMS will experience a concurrent mode failure.
There are multiple ways to attempt to avoid this failure:
▪ Make the old generation larger, either by shifting the proportion of the new generation to
the old generation, or by adding more heap space altogether.
▪ Run the background thread more often.
▪ Use more background threads.