using Concurrent Mark Sweep GC Collector?

Question

This question is based on my understanding from section Java Garbage Collectors of link Looks like jvm by default uses "Parallel GC" on windows 7 as i confirmed it -XX:+PrintCommandLineFlags -version. This article also says

The parallel garbage collector uses multiple threads to perform the young generation garbage collection. This collector should be used when a lot of work need to be done and long pauses are acceptable

i am not sure which collector is used for tenured space collection by Parallel GC?

Also i could not think of applications where long pauses are acceptable(will cause less responsiveness). Anyone would like to less pauses for GC and make app as responsive as it can.

Then i read Concurrent Mark Sweep (CMS) Collector which collects the tenured generation

CMS says it require low pause times and can share resources with the garbage collection.

My question is should not most of web applications use Concurrent Mark Sweep (CMS) Collector because of its responsiveness.? I am sure there must be some other factors also to make the decision but after going thru this link to me feels like i should change the default GC type to Concurrent Mark Sweep (CMS) Collector. Any thoughts/insights?

Further i think application can be best if we use CMS Collector and parallel collector together where CMS is used for old generation and parallel fpr younger generation

Answer 1

i am not sure which collector is used for tenured space collection by Parallel GC?

Going off of this page, if you use the parallel GC the parallel scavenge collector is used for the young generation and the parallel mark/sweep collector is used for the old generation (aka tenured generation). So I guess the answer is "The Parallel GC is used for tenured space collection by the Parallel GC". Bit of a circular statement, but I suppose it makes sense.

Also i could not think of applications where long pauses are acceptable(will cause less responsiveness). Anyone would like to less pauses for GC and make app as responsive as it can.

"Long pause" is relative, and whether they are acceptable depends on the type of application and its use. Applications which require quick user interaction, such as games, would probably require low pause times, while applications that are long-running, have little user interaction (overnight batch jobs, processing jobs which can run for several days, possibly servers which run for long periods of time, etc.), or don't require fast user interaction (word processors? But who writes word processors in Java?) wouldn't have nearly as strict pause requirements, so pauses would be OK for those. In addition, pauses are not the only GC factor to consider, so even if pauses are OK there are other reasons that a GC with longer pauses would be chosen. I'll explain further down.

My question is should not most of web applications use Concurrent Mark Sweep (CMS) Collector because of its responsiveness.?

The CMS collector has drawbacks. In the article you mentioned, there's this line:

Normally the concurrent low pause collector does not copy or compact the live objects. A garbage collection is done without moving the live objects.

So no heap compaction would lead to heap fragmentation, which could be detrimental to performance. This post states another drawback (I'm not sure exactly how reliable this post is, but it seems to be pretty decent at a first glance):

A more important disadvantage of the CMS collector is related to the fact that it cannot be started when the Old generation heap is full. Once the Old generation is full, it is too late for the CMS and it must then fall back to the usual stop-the-world strategy (announced by a “concurrent mode failure” in the GC log).

...

The biggest disadvantage of the CMS, however, is related to the fact that it does not compact the Old generation heap. It therefore carries the risk of heap fragmentation and severe operations degradation over time.

...

It is obvious that with these settings the JVM worked well for almost 14 hours under loadtest conditions (in production and with lower load this treacherously benign period may last much longer). Then suddenly there were very long GC pauses which actually stopped the JVM for about half of the remaining time. There were not only attempts to clean up the mess in the Old generation which lasted more than 10 seconds but even New generation GC pauses were in the seconds range because the collector spent a lot of time searching for space in the Old generation when it tried to promote objects from new to Old generation.

There is more detail in the blog post, which you should probably read as there's a lot covered outside the quote here as well as some fantastic demonstrations. But the point to take away is that the CMS collector is not a one-size-fit-all collector. It has its drawbacks as well, which might cause a programmer to pick a different collector instead. Using it as the default may be OK for short-running applications, but for long-running applications such behavior would be very bad...

Further i think application can be best if we use CMS Collector and parallel collector together where CMS is used for old generation and parallel fpr younger generation

This is actually the default mode when you pass the -XX:+UseConcMarkSweepGC argument to your VM. But as stated above, you may want to really take some time to think about what collector you want to use. Picking a collector without considering your use case probably isn't a good idea. (Side note: I thought I saw some document from Oracle on how to decide what GC to use, but I can't find it any more...)

In addition, you might want to consider the shiny new G1 collector, if you have Java 7u4 or later. It's supposed to be the replacement for the CMS collector.