The concurrent mark sweep collector, also known as the concurrent collector or CMS, is targeted at applications that are sensitive to garbage collection pauses. It performs most garbage collection activity concurrently, i.e., while the application threads are running, to keep garbage collection-induced pauses short. The key performance enhancements made to the CMS collector in JDK 6 are outlined below. See the documents referenced below for more detailed information on these changes, the CMS collector, and garbage collection in HotSpot.
Note that these features only apply when the CMS collector is in use; the
option -XX:+UseConcMarkSweepGC selects the CMS collector.
The System.gc() and Runtime.getRuntime().gc()
methods instruct the JVM to run the garbage collector to recycle unused
objects. The HotSpot implementation of these methods currently stops all
application threads to collect the entire heap, which can result in a
lengthy pause particularly when the heap is large. This works against the
goal of the CMS collector to keep pauses short.
In JDK 6, the CMS collector can optionally perform these collections
concurrently, to avoid a lengthy pause in response to a
System.gc() or Runtime.getRuntime().gc() call.
To enable this feature, add the option
-XX:+ExplicitGCInvokesConcurrent
java command line.
Several changes were made that increase the default size of the young generation when the CMS collector is used:
The primary effect of these changes is to improve application performance by reducing garbage collection overhead. However, because the default young generation size is larger, applications may also see larger young generation pause times and a larger memory footprint. If necessary, please see the documents referenced below for more details on generations, survivor spaces and the options available for adjusting their sizes.
The CMS collector now uses multiple threads to perform the concurrent marking task in parallel on platforms with multiple processors. This reduces the duration of the concurrent marking cycle, allowing the collector to support applications with larger numbers of threads and higher object allocation rates, particularly on large multiprocessor machines. Prior releases used only a single thread for concurrent marking, limiting the collector's ability to keep up with applications with very high object allocation rates.
The HotSpot memory management whitepaper provides more detail about the CMS collector and the other collectors available in HotSpot, as well as descriptions of the generations, survivor spaces and other memory management concepts.
The HotSpot documentation page contains links to Garbage Collection Tuning Guides, specific to each release, which include guidelines for choosing the garbage collector that best suits your application and techniques that can help reduce garbage collection overhead.