Concurrent Mark Sweep Collector Enhancements
- Description
- System.gc() Performed Concurrently
- Larger Default Young Generation Size
- Parallel Marking
- More Information
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 minimum young generation size was increased from 4MB to 16MB.
- the proportion of the overall heap used for the young generation was increased from 1/15 to 1/7.
- the survivor spaces are now used by default, and their default size was increased. (In prior releases the survivor spaces were disabled by default with the CMS collector.)
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.