Michael Kopp About the Author

Michael is aTechnical Product Manager at Compuware. Reach him at @mikopp

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 oft 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. In one of my next posts I will show how we can monitor the impact garbage collection has on the application in a better way.


Comments

  1. Erik Onnen says:

    ” Unfortunately since JDK6 Update 23 we cannot monitor for a major GC in case of the concurrent strategy anymore.” – That’s not entirely correct. A tiny bit of JVMTI will allow you to easily track both full GCs and duration. See
    http://download.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#GarbageCollectionStart

    • I should have been more specific. You cannot track it via JMX anymore. But you are right, solutions like dynaTrace that can leverage JVMTI still see major gcs, or rather we see suspensions, which is not the same as we learned ;-) .

  2. Why not using C++ and getting rid of all this shaky GC tuning knobs? I never missed GC and RAII gives you clean code. Compare also heap sizes. I don’t like swapping.

    C++ is an open sound standard/platform.

  3. I’m wondering about the results of java garbage collection in conjunction with cloud storage. As understanding application resources directly coincides with how we store things in the cloud or otherwise, it’s important to understand how garbage collection fits into this equation. What steps is java taking to account for the cloud, and how do the old and young generation’s roles differentiate during this process.

  4. Took me time to read all the comments, but I really enjoyed the article. It proved to be very useful to me and I am sure to all the commenters here! It’s always nice when you. IT jobs

  5. Such a great article! Did you ever hear about Azul System’s JVM? Once the company that I work for is thinking of using it, I’d like to know some detailed information about it’s GC, but from someone that doesn’t work for them, in order to have a different and not “pre-defined” point of view.

    Thanks a lot!

    Great blog, and great articles!

    Carry on, keep it up!

  6. Digitalglory says:

    A short, but very thoughtful and informative post. I especially like the effort made to define a major and minor GC. I haven’t seen this done in many places and think this article succeeds very well. An enlightening read!

    Danny – proud owner of Yamaha P95 piano

  7. Does anyone know if this sort of thing works on a brand new ipad?

Comments

*


seven − = 1