Remove the Concurrent Mark Sweep (CMS) garbage collector from the set of usable garbage collection algorithms.
- Only disable compilation but keep source code of the CMS garbage collector.
- Remove any other garbage collector.
- Remove the CMS garbage collector retroactively in earlier releases.
The Oracle garbage collection team regularly assesses the cost/benefit of garbage collectors it maintains.
More than two years ago in JEP 291 we deprecated the CMS collector for future removal to free up resources for future work currently bound by testing, bugfixing and keeping CMS working. This long period allowed for interested credible contributors in the community to step up for maintenance, however this has not occurred.
In the meantime the Oracle garbage collection team introduced a new garbage collector, ZGC, and Red Hat contributed the Shenandoah collector. Oracle further improved G1, which has been its designated successor since initial introduction in JDK6u14. So we believe that the available garbage collection algorithms provided by the Hotspot VM, if they do not surpass CMS' performance, have a small enough overhead even for applications that are highly tuned to CMS to be able to move away from it today.
Future improvements on existing garbage collectors are expected to reduce the need for CMS further, so there is very little motivation for the Oracle Hotspot garbage collection team or any other contributor according to feedback received at OCW 2019 to maintain CMS further.
This change will disable compilation of the CMS collector, remove the contents of the gc/cms directory and remove options pertaining solely to the CMS collector. References to the CMS collector in the documentation will also be purged. Tests trying to use the CMS collector will be removed or adapted as necessary.
Trying to use the CMS collector via -XX:+UseConcMarkSweepGC 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 the CMS collector could be kept in the repository but not compiled. However without maintainer the code would obsolete quickly and would give a false impression of being supported in any way.
Users can move to the G1 garbage collector or any of the other collectors. Users that absolutely require CMS may still use it as long as it remains supported in earlier releases.
Risks and Assumptions
We assume that the current selection of existing and supported garbage collectors provide a viable upgrade path. Future development is expected to further improve these collectors.
Additionally, we do not expect that other interested credible contributor in the community will step up for maintenance. In this case this JEP might be withdrawn.