Taking out the trash

JEP 363: Remove the Concurrent Mark Sweep (CMS) Garbage Collector

Chris Stewart
JEP 363
© Shutterstock / SimoneN

A new Java enhancement proposal, JEP 363, has graduated from being a simple draft. It proposes to remove the Concurrent Mark Sweep garbage collector, which was deprecated two years ago to accelerate the development of other collectors. Let’s take a closer look at the future of Java.

In August 2019, Thomas Schatzl submitted a JEP draft proposing the Concurrent Mark Sweet garbage collector be removed. This was not unexpected since it was already deprecated in Java 9 (JEP 291) and users had two years to step up and volunteer to take care of the project. However, nobody took up the CMS mantle, and so the JEP draft how now evolved into a full-fledged Java Enhancement Proposal that is proposed to target JDK 14. Ladies and gentlemen: JEP 363!

JEP 363: Remove the Concurrent Mark Sweep (CMS) Garbage Collector

Since Concurrent Mark Sweep was deprecated in JDK 9, two new garbage collectors, ZGC and Shenandoah, have come into being. The G1 garbage collector, which was originally intended as the successor to CMS (way back in the days of JDK 6), has also seen plenty of improvement during this time.



Schatzl’s proposal states, “at this point the garbage collectors available in the Hotspot JVM, if they do not surpass CMS’s performance, have a small enough overhead that it is now safe to remove CMS.”

What will the removal of CMS involve? Schatzl writes:

This change will disable compilation of CMS, remove the contents of the gc/cms directory in the source tree, and remove options that pertain solely to CMS. References to CMS in the documentation will also be purged. Tests that try to use CMS will be removed or adapted as necessary.

SEE ALSO: Java 14: Six JEPs proposed to target JDK 14

Following its removal, attempting to use CMS with -XX:+UseConcMarkSweepGC will trigger an error message:

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

The VM will then carry on using whichever garbage collector is selected as the default.


The JEP notes that an alternative approach would leave the CMS code in the repository uncompiled, but Schatzl expresses concerns that not only would it quickly become obsolete, but it could also create the false impression that it is still being supported.

Instead of Concurrent Mark Sweep, users can move over to the intended successor, G1, or use any of the other collectors. Furthermore, since CMS will only be removed from JDK 14 onwards, the earlier releases that still support it will remain an option for those who absolutely need Concurrent Mark Sweep instead of one of the alternatives.

For more information, check out JEP 363 in all its glory.

Chris Stewart
Chris Stewart is an Online Editor for He studied French at Somerville College, Oxford before moving to Germany in 2011. He speaks too many languages, writes a blog, and dabbles in card tricks.

Inline Feedbacks
View all comments