CMS Deprecated. Next Steps?

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 onwards, if you launch the application with -XX:+UseConcMarkSweepGC (an argument which will activate the CMS GC algorithm), you are going to see 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 Is Our CMS Deprecated?

If there is a lot of baggage to carry, it’s hard to move forward quickly. That is what's happening in the case of CMS as well. CMS is a highly configurable, sophisticated algorithm and thereby causes a lot of complexities to the GC code base in JDK. Only if the JDK development team can simplify the GC code base, they can accelerate and innovate in GC arena. The table below summarizes the number of JVM arguments that can be passed to each GC algorithm.

GC Algorithm

JVM arguments(approximately)

Common to all

50

Parallel

6

CMS

72

G1

26

ZGC

8

There are around 50 GC-related arguments can be passed to JVM, which is common to all GC algorithms. On top of these 50 arguments, just for CMS alone, you can pass 72 additional arguments. This is a much greater number of arguments than any other GC algorithms, as summarized in the above table. Thus, you can see the coding complexity required by the JDK team to support all these arguments.

What Are the Next Steps if You Are Using CMS?

As far as I can tell, I see three different choices in front of us:

1. Switch to G1 GC algorithm
2. Switch to Z GC algorithm (Early access in JDK 11, 12)
3. Continue with CMS

Let’s explore each option in this section.

(1). 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.

(2). 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 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 Z GC algorithm. Our preliminary analysis of Z GC is showing excellent results.

(3). Continue With CMS

For certain applications, we have seen CMS to delivery 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 convinced the CMS algorithm is the marriage made for your application in heaven, you can consider running with the CMS algorithm itself. There are even arguments continuing to keep CMS alive in this OpenJDK JDK9-dev mailing list . Based on my own personal experience, I am seeing the features and APIs deprecated in Java 1.1 continuing to exist even in Java 12 (even after 20 years). It seems all deprecated APIs and features seem to survive (and never truely die). Thus, continuing to run on CMS is also an option. Of course, it’s your call as well as your application stakeholder's call.

Conclusion

Note that each application is unique and different. So, don’t get carried away by the journals and literature you find on the Internet talking about GC tuning/tweaking (including this article). When you instrument a new GC setting, do thorough testing, benchmark performance characteristics, study these KPIs , and then make a conscious decision.

Good luck!