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 GC code base and accelerate new development.

Thus from Java 9, if you launch the application with -XX:+UseConcMarkSweepGC (argument which will activate 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 CMS is deprecated?


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

CMS.jpg

There are around 50 GC related arguments can be passed 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. 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 if you are using CMS?


As I am writing this blog on Feb’ 2019, I can see 3 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 default GC algorithm since java 9. So, you may consider moving your application to this algorithm. It may provide better performance characteristics than 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 to bringing down 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, 12. So if your application is running on java 11, 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 which aren’t matched by G1 GC even after lot of tuning. So, if you have explored other two options and convinced 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. On my personal experience, I am seeing the features and APIs which are deprecated in Java 1.1, are continuing to exist even in Java 12 (even after 20 years). It seems all deprecated APIs and features seems 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.

Conclusion

Note that each application is unique and different. So, don’t get carried away by the journals, literatures 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.

Reference article: https://blog.gceasy.io/2019/02/18/cm...ed-next-steps/