Garbage Collection: Serial vs. Parallel vs. Concurrent-Mark-Sweep

what's the difference between the serial, parallel and CMS (Concurrent-Mark-Sweep) collectors?

 

first of all, let's take a look which collectors operate on the young generation and which on the tenured (old) generation:

 

• the following collectors operate on the young generation:

-XX:+UseSerialGC
-XX:+UseParallelGC
-XX:+UseParNewGC

 

• the following collectors operate on the old generation:

-XX:+UseParallelOldGC
-XX:+UseConcMarkSweepGC

 

• what's the difference between the Serial and the Parallel collector?

both the serial and parallel collectors cause a stop-the-world during the GC.
so what's the difference between them?
a serial collector is a default copying collector which uses only one GC thread for the GC operation, while a parallel collector uses multiple GC threads for the GC operation.

 

• what's the difference between the Parallel and the CMS collector?

the CMS performs the following steps (all made by only one GC thread):
- initial mark
- concurrent marking
- remark
- concurrent sweeping

 

there are two differences between a parallel and a CMS collectors:

1) the parallel uses multiple GC threads, while the CMS uses only one.
2) the parallel is a 'stop-the-world' collector, while the CMS stops the world only during the initial mark and remark phases.
during the concurrent marking and sweeping phases, the CMS thread runs along with the application's threads.

 

• if you wish to combine both parallelism and concurrency in your GC, you can use the following:

-XX:UserParNewGC for the new generation (multiple GC threads)
-XX:+UseConcMarkSweepGC for the old generation (one GC thread, freezes the JVM only during the initial mark and remark phases)

In theory, the CMS should be used when you you want to reduce the time you application spends on GC freezes (Stop-The-World) by making the GC working concurrently with your application. you'll use parallel when you want to reduce the application freezes but not in the cost of interfering with your application threads. I don't like the CMS because it didn't work for me, and I suspect it made things worst. one of the possible reasons is mentioned here: http://groups.google.com/group/shibboleth-users/browse_thread/thread/5527f50b503866ac regarding when to deal with the GC - I think that the JVM configuration is under-estimated. most applications only configure the heap minimal and maximal size (usually to the wrong values, but that's another issue) and that's it. they don't deal with the following questions: - what's the size of the young generation? - what's the size of the tenured generation? - what should be the size of the permanent generation? - which collectors are best for the young and tenured generation? - how much memory should threads use on the stack? - should I use the distributed GC? and more... when you run in troubles? the most frequent cases are when you get Out-of-memory or PermGen. then you have to handle the problem by changing the JVM configuration. but that's the obvious case. the other case is when you see your application freezes for a long time. in that case you can check if the GC is the reason, and if so - start to understand how to prevent this by configuring the collectors (or the Distributed GC - http://www.tikalk.com/java/application-freezes-too-many-full-gcs) but I think you should always configure the JVM parameters, mainly because the default configuration that Sun provides isn't optimal.

Ref: http://www.tikalk.com/java/garbage-collection-serial-vs-parallel-vs-concurrent-mark-sweep

Young generation garbage collection algorithms

The (original) copying collector (Enabled by default). When this collector kicks in, all application threads are stopped, and the copying collection proceeds using one thread (which means only one CPU even if on a multi-CPU machine). This is known as a stop-the-world collection, because basically the JVM pauses everything else until the collection is completed.

The parallel copying collector (Enabled using -XX:+UseParNewGC). Like the original copying collector, this is a stop-the-world collector. However this collector parallelizes the copying collection over multiple threads, which is more efficient than the original single-thread copying collector for multi-CPU machines (though not for single-CPU machines). This algorithm potentially speeds up young generation collection by a factor equal to the number of CPUs available, when compared to the original singly-threaded copying collector.

The parallel scavenge collector (Enabled using -XX:UseParallelGC). This is like the previous parallel copying collector, but the algorithm is tuned for gigabyte heaps (over 10GB) on multi-CPU machines. This collection algorithm is designed to maximize throughput while minimizing pauses. It has an optional adaptive tuning policy which will automatically resize heap spaces. If you use this collector, you can only use the the original mark-sweep collector in the old generation (i.e. the newer old generation concurrent collector cannot work with this young generation collector).

http://www.javaperformancetuning.com/news/qotm026.shtml

XX:-UseParallelGC = Use parallel garbage collection for scavenges. (Introduced in 1.4.1).

-XX:-UseParallelOldGC = Use parallel garbage collection for the full collections. Enabling this option automatically sets -XX:+UseParallelGC. (Introduced in 5.0 update 6.)

where Scavenges = Young generation GC.

http://stackoverflow.com/questions/6236726/whats-the-difference-between-parallelgc-and-paralleloldgc