JEP 363: Remove the Concurrent Mark Sweep (CMS) Garbage CollectorJEP 363: Remove the Concurrent Mark Sweep (CMS) Garbage CollectorOwnerThomas SchatzlTypeFeatureScopeImplementationStatusClosed / DeliveredRelease14Componenthotspot / gcDiscussionhotspot dash gc dash dev at openjdk dot java dot netEffortSDurationSRelates toJEP 291: Deprecate the Concurrent Mark Sweep (CMS) Garbage CollectorReviewed byErik Helin, Mikael Vidstedt, Per LidenEndorsed byMikael VidstedtCreated2019/08/03 19:52Updated2020/06/18 13:39Issue8229049Summary
Remove the Concurrent Mark Sweep (CMS) garbage collector.
Non-Goals

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.

Motivation
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.
Description
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.
Alternatives
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.
InstallingContributingSponsoringDevelopers' GuideVulnerabilitiesJDK GA/EA BuildsMailing listsWiki
                      · IRCBylaws · CensusLegalWorkshopJEP ProcessSource codeMercurialGitHubToolsGitjtreg harnessGroups(overview)AdoptionBuildClient LibrariesCompatibility & Specification ReviewCompilerConformanceCore LibrariesGoverning BoardHotSpotIDE Tooling & SupportInternationalizationJMXMembersNetworkingPortersQualitySecurityServiceabilityVulnerabilityWebProjects(overview,
      archive)AmberBabylonCRaCCaciocavalloClosuresCode ToolsCoinCommon VM InterfaceCompiler GrammarDetroitDevelopers' GuideDevice I/ODukeGalahadGraalIcedTeaJDK 7JDK 8JDK 8 UpdatesJDK 9JDK
      (…,
       21,
       22,
       23)JDK UpdatesJavaDoc.NextJigsawKonaKullaLambdaLanaiLeydenLilliputLocale EnhancementLoomMemory Model UpdateMetropolisMission ControlMulti-Language VMNashornNew I/OOpenJFXPanamaPenrosePort: AArch32Port: AArch64Port: BSDPort: HaikuPort: Mac OS XPort: MIPSPort: MobilePort: PowerPC/AIXPort: RISC-VPort: s390xPortolaSCTPShenandoahSkaraSumatraTiered AttributionTsanType AnnotationsValhallaVeronaVisualVMWakefieldZeroZGC

        © 2024 Oracle Corporation and/or its affiliates
        Terms of Use
        ·
        
            License: GPLv2
        · Privacy
        · Trademarks
