Remove the Concurrent Mark Sweep (CMS) garbage collector.
- It is not a goal to remove any other garbage collector.
- It is not a goal to remove the CMS garbage collector from releases prior to the release to which this JEP is targeted.
More than two years ago in, JEP 291, we deprecated the CMS collector for removal in a future release, in order to accelerate the development of other collectors. During this time, no credible contributors stepped up to take on the maintenance of CMS.
During this time we’ve also seen the introduction of two new collectors, ZGC and Shenandoah, along with further improvements to G1, which has been the intended successor to CMS since JDK 6. 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. We expect that future improvements to the existing collectors will reduce the need for CMS even further.
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.
Trying to use CMS via the
-XX:+UseConcMarkSweepGC option will result in the following warning message:
Java HotSpot(TM) 64-Bit Server VM warning: Ignoring option UseConcMarkSweepGC; \ support was removed in <version>
and the VM will continue execution using the default collector.
The code for CMS could be kept in the repository but not compiled. Without a maintainer, however, the code would become obsolete quickly yet might give a false impression of being supported.
Users can move to the G1 garbage collector or any of the other collectors. Users that absolutely require CMS may still use it for as long as it remains supported in earlier releases.