CMS Java Garbage Collector deprecated: What are the next steps?
JDK 9 included the deprecation of the Concurrent Mark Sweet (CMS) GC algorithm. In Java 9 onward, launching the application with -XX:+UseConcMarkSweepGC provides a warning message. In this article, Ram Lakshmanan explains why CMS was deprecated, what your next steps are, and offers some alternative options to take.
The popular Concurrent Mark Sweep (CMS) GC algorithm is deprecated in JDK 9. According to JEP-291, this decision has been made to reduce the maintenance burden of the GC code base and accelerate new development.
Thus from Java 9 onward, if you launch the application with -XX:+UseConcMarkSweepGC (an argument which will activate CMS GC algorithm), you are going to see the below WARNING message:
Java HotSpot(TM) 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release.
Why was CMS deprecated?
If there is a lot baggage to carry, it’s hard to move forward quickly. This is what happening in CMS’s case as well. CMS is a highly configurable, sophisticated algorithm and thereby inherits a lot of complexities into the GC code base in the JDK. Only if the JDK development team can simplify the GC code base, then they can accelerate and innovate in the GC arena.
The below table summarizes the number of JVM arguments that can be passed to each GC algorithm.
There are around 50 GC related arguments that can pass to JVM, which are common to all GC algorithms. On top of these 50 arguments, just for CMS alone you can pass 72 additional arguments – a way greater number of arguments than any other GC algorithms as summarized in the above table. Thus, you can see the coding complexity required by JDK team to support all these arguments.
What are the next steps?
I can see 3 different choices in front of us:
- Switch to G1 GC algorithm
- Switch to Z GC algorithm (Early access in JDK 11, 12)
- Continue with CMS
Let’s explore each option in this section.
Switch to G1 GC algorithm
G1 GC has become the default GC algorithm since Java 9. So, you may consider moving your application to this algorithm. It may provide better performance characteristics than the CMS GC algorithm. It’s much easier to tune as there are comparatively a smaller number of arguments. Also, it provides options to eliminate duplicate strings from memory. If you can eliminate duplicate strings, it may help you bring down the overall memory footprint.
Switch to Z GC algorithm
Z GC is a scalable low-latency garbage collector. Its goal is to keep GC pause times less than 10ms. Early access of the Z GC algorithm is available in Java 11 and 12. So, if your application is running on Java 11 or 12. You may consider upgrading to the Z GC algorithm. Our preliminary analysis of Z GC shows excellent results.
Continue with CMS
For certain applications, we have seen CMS deliver spectacular results that aren’t matched by G1 GC even after a lot of tuning. So, if you have explored the other two options and are convinced the CMS algorithm is the marriage made for your application in heaven, you can consider running with CMS algorithm itself. 😊
There are even arguments continuing to keep CMS alive in this OpenJDK JDK9-dev mailing list. In my personnel experience, I am seeing the features and APIs which are deprecated in Java 1.1, continue to exist even in Java 12 (after 20 years). It seems all deprecated APIs and features seem to survive (& never die). Thus, continuing to run on CMS is also an option. Of course, it’s your call and your application stakeholders’ call.
Note that each application is unique and different. So, don’t get carried away by the journals and literature you find on the internet that talks about GC tuning/tweaking (including this article). When you instrument new GC setting, do thorough testing, benchmark performance characteristics, study these KPIs, and then make a conscious decision.