JEP 144: Reduce GC Latency for Large HeapsJEP 144: Reduce GC Latency for Large HeapsAuthorJesper WilhelmssonOwnerTony PrintezisTypeFeatureScopeImplementationStatusCandidateComponenthotspot / gcDiscussionhotspot dash gc dash dev at openjdk dot java dot netEffortXLDurationXLReviewed byBengt RutissonEndorsed byMikael VidstedtCreated2011/11/01 20:00Updated2014/10/06 20:59Issue8046134Summary
Improve the performance of applications that require large heaps, of up
to 32GB, by reducing garbage-collector latency.
Goals
Enable the use of 32GB heaps with 60% live data and fairly consistent
250--500ms pause times, as specified by pause target, for a set of
relevant benchmarks. Average pause times can fluctuate ±10%.
Non-Goals
Pause-time guarantees are not required. It is not a goal or a requirement
to improve GC characteristics for smaller heap sizes that are currently
served well by existing GC technology.
Motivation
We see continued increases in random-access memory (RAM) sizes. For
workloads that require low and consistent GC pause times, the JVM using
the CMS collector can manage heap sizes of up to 4--8GB. A normal
low-cost server now has much more memory than can be effectively used
with a single JVM instance for these workloads, so Java applications are
often scaled out across several JVM instances. While this may be a viable
solution for many applications, vertical scaling solutions are
effectively blocked by JVM GC limitations. Non-garbage-collected
environments do not suffer from these limitations. The intent of this
proposal is to enable low and consistent pause times with large RAM sizes
so that Java is viable for existing use cases where GC limitations have
forced complicated re-architecting or migration to other platforms.
Description
This will done by improving the G1 collector. There are a number of CRs
that we aim to work on to improve performance. The list below is our
starting point; it is not the final list of CRs. Extensive performance
measurements are required to find the actual bottlenecks and choose the
CRs (and write new ones) for those areas where more work is needed.


6484965: G1: piggy-back liveness accounting phase on marking


6868854: G1: eliminate serial Other times at the end of a GC pause


6949254: G1: introduce framework for concurrent operations in G1


6976060: G1: humongous object allocations should initiate marking
cycles when necessary


7022456: G1: significant memory footprint increase compared to other
collectors during application


7052429: G1: Avoid unnecessary scanning of humongous regions during
concurrent marking


7068229: G1: Dynamically enable MT reference processing for remark
pauses


7084525: G1: Generate ergonomic decision log records for young gen
sizing and for pause prediction


7098085: G1: partially-young GCs not initiated under certain
circumstances


7098512: G1: do not clear the next marking bitmap at the start of a
Full GC


Apart from these bugs and RFEs, to achieve constant pause times in the
250--500ms range we need to avoid full GCs completely. This will most
likely require a new scheme where, rather than start a full GC, we
instead increase the amount of work we do gradually if we notice that we
can't keep up with the allocation rate or if fragmentation becomes an
issue.
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
