Major GCs – Separating Myth from Reality

In a recent post we have shown how the Java Garbage Collection MXBean Counters have changed for the Concurrent Mark-and-Sweep Collector. It now reports all GC runs instead of just major collections. That prompted me to think about what a major GC actually is or what it should be. It is actually quite hard to find any definition of major and minor GCs. This well-known Java Memory Management Whitepaper only mentions in passing that a full collection is sometimes referred to as major collection.

Stop-the-world

One of the more popular definitions is that a major GC is a stop-the-world event. While that is true, the reverse is not. It is often forgotten that every single GC, even a minor one, is a stop-the-world event. Young Generation collections are only fast if there is a high mortality rate among young objects. That’s because they copy the few surviving objects and the number of objects to check is relatively small compared to the old generation. In addition they are done in parallel nowadays. But even the Concurrent GC has to stop the JVM during the initial mark the remark.

That brings us immediately to the second popular definition.

The Old Generation GC

Very often GC runs in the old generation are considered major GCs. When you read the tuning guides or other references, GC in the tenured or old generation is often equaled with a major GC. While every major GC cleans up the old generation, not all runs can be considered major. The CMS (Concurrent Mark and Sweep) was designed to run concurrent to the application. It executes more often than the other GCs and only stops the application for very short periods of time. Until JDK6 Update 23 its runs were not reported via its MXBean. Now they are, but the impact on the application has not changed and for all intents and purposes I would not consider them major runs. In addition, not all JVMs have a generational Heap, IBM and JRockit both feature a continuous Heap on default. We would still see GC runs that we would either consider Minor or Major. The best definition that we could come up with is that a major GC stops the world for a considerable amount of time and thus has major impact on response time. With that in mind there is exactly one scenario that fits all the time: a Full GC.

Full GC

According to the before-mentioned white paper a Full GC will be triggered whenever the heap fills up. In such a case the young generation is collected first followed by the old generation. If the old generation is too full to accept the content of the young generation, the young generation GC is omitted and the old generation GC is used to collect the full heap, either in parallel or serial. Either way the whole heap is collected with a stop-the-world event. The same is true for a continuous heap strategy, as apart from the concurrent strategy every GC run is a Full GC!

In case of the concurrent GC the old generation should never fill up. Hence it should never trigger a major GC, which is of course the desired goal. Unfortunately, the concurrent strategy will fail if too many objects are constantly moved into the old generation, the old generation is too full or if there are too many allocations altogether. In that case it will fall back on one of the other strategies and in case of the Sun JVM will use the Serial Old Collector. This in turn will of course lead to a collection of the complete heap. This was exactly what was reported via the MXBean prior to Update 23.

Now we have a good and useful definition of a major GC. Unfortunately since JDK6 Update 23 we cannot monitor for a major GC in case of the concurrent strategy anymore. It should also be clear by now that monitoring for major GCs might not be the best way to identify memory problems as it ignores the impact minor GCs have.