Java Concurrent Mark & Sweep (CMS) algorithm is known for concurrently marking and sweeping the memory regions without a significant pause. However, the Concurrent Mark & Sweep algorithm took an unexpected turn when it was deprecated in Java 9 and starting from Java 14 it was completely removed. Java Enhancement Proposal 363, sheds light on this decision, attributing the removal due to the absence of credible contributors stepping up to maintain CMS.

In this post, we’ll talk about what this means if you’ve been using CMS. What options do you have now, and how does this impact your Java applications? We’ll explore the alternatives and help you figure out what to do in the new world of Java memory management.

CMS GC algorithm

CMS algorithm is known to support applications with following types of workloads:

a. Low-latency Requirements: When application demands low and predictable pause times, such as in real-time systems.

b. Frequent Object Creation and Deletion Environments: In situations where objects are created and become unreachable frequently, CMS can efficiently reclaim memory without causing prolonged interruptions, making it suitable for applications with dynamic memory patterns.

c. JVMs with Limited Resources: In environments where system resources, especially memory, are constrained, CMS can be a pragmatic choice as it aims to balance memory management efficiency with minimal disruption.

Despite its strengths, the CMS GC algorithm became increasingly complex to maintain within the JDK due to a multitude of JVM arguments. With a lack of active contributors to support and enhance it, the JDK team made the decision to completely remove the CMS algorithm from Java 14.

CMS Algorithm removed

If you are using JDK 14 or a later version and attempt to configure the CMS algorithm by passing the flag -XX:+UseConcMarkSweepGC, you will encounter the following error message:

Java HotSpot(TM) 64-Bit Server VM warning: Ignoring option UseConcMarkSweepGC; support was removed in <version>

This warning informs you that the support for the CMS algorithm has been completely removed in the specified version of the Java Virtual Machine (JVM). Consequently, any attempt to use the CMS algorithm will be ignored, and alternative garbage collection configurations should be considered.

What to do if you are using a CMS algorithm?

If your application currently relies on the CMS (Concurrent Mark & Sweep) algorithm and you are running on JDK 14 or a newer version, it’s crucial to make adjustments. Here are viable alternatives to consider, each with its own strengths and use cases:

1. Switch to G1 GC

2. Switch to Shenandoah GC

3. Switch to ZGC

Note: There are other GC algorithms like Serial GC, Parallel GC in Oracle JDK/OpenJDK. But I didn’t list them as viable alternatives to the CMS GC algorithm. Because they are pretty old algorithms and don’t give the cutting edge performance characteristics that are demanded by the modern applications.

1. Switch to G1 GC

If your application has requirements such as predictable pause times, balanced throughput and latency, or adaptability to dynamic workloads, the G1 Garbage Collector is a robust option. To make the switch to G1 GC algorithm, use the following JVM argument:

-XX:+UseG1GC

If you are considering switching to G1 GC, you can learn more about tuning G1 GC in this article.  

2. Switch to Shenandoah GC 

Consider Shenandoah GC if your application demands consistently low pause times, operates with large heap sizes, requires predictable response times, or experiences dynamic workloads. To adopt Shenandoah GC, use the following JVM argument:

-XX:+UseShenandoahGC

If you are considering switching to Shenandoah GC, you can learn more about tuning Shenandoah GC in this article.

3. Switch to ZGC 

ZGC is well-suited for applications with large heap sizes, low-latency requirements, and varied workloads. If your application falls into these categories, consider switching to ZGC using the following JVM argument:

-XX:+UseZGC -XX:+ZGenerational

If you are considering switching to ZGC, you can learn more about tuning ZGC in here.

Study GC behaviour before switching to new algorithm

Before transitioning to a new garbage collection (GC) algorithm in your production environment, it’s crucial to thoroughly study its performance characteristics. This can be best achieved by conducting a comprehensive analysis of the GC log, which contains detailed information about garbage collection events, memory usage, and other pertinent metrics.

Several tools are available to assist in this analysis, including GCeasy, IBM GC & Memory visualizer, HP Jmeter, Google Garbage cat. These tools allow you to visualize memory allocation patterns, identify potential bottlenecks, and assess the efficiency of garbage collection. Here is a guide on GC log analysis.

To enhance your understanding further, consider watching this video tutorial on GC log analysis. it provides practical insights and tips on interpreting GC logs effectively.

Conclusion

In the world of Java, saying goodbye to the Concurrent Mark & Sweep (CMS) algorithm in Java 14 is a big change. We hope this article has provided valuable insights to help you navigate this substantial change effectively.