JEP 149: Reduce Core-Library Memory UsageJEP 149: Reduce Core-Library Memory UsageAuthorsRoger Riggs, Hinkmond Wong, David HolmesOwnerRoger RiggsTypeFeatureScopeImplementationStatusClosed / DeliveredRelease8Componentcore-libsDiscussioncore dash libs dash dev at openjdk dot java dot netEffortMDurationMReviewed byBrian GoetzEndorsed byBrian GoetzCreated2012/01/04 20:00Updated2016/02/18 21:20Issue8046139Summary
Reduce the dynamic memory used by core-library classes without adversely
impacting performance.
Success Metrics
Existing workloads and metrics including SPECjbb2005 and SPECjvm98 will
be used to judge the benefit and impact of these changes.
Motivation
Reducing the dynamic memory (heap) usage of core-library classes will
increase the size of applications that can be run within a given
allocation of memory for the Java runtime, allow more applications to be
run with the same dynamic footprint, and increase the throughput of
applications due to more efficient memory usage.
Description
The work to find practical reductions in the amount of dynamic memory
parallels other performance work. Typical workloads will be identified
and examined to identify likely opportunities for improvements. Various
improvements to library classes to reduce heap usage and improve related
native implementations will be prototyped and evaluated for
effectiveness.  The performance impact will be measured using existing
workloads and metrics including SPECjbb2005 and SPECjvm98.
The improvements that reduce dynamic memory usage while not impacting
performance and are long-term maintainable in the source will be
incorporated.  Changes that are only effective for some applications
should be configurable so they can be enabled or disabled as needed.
Candidate: Reduce Object Sizes
Several fields in java.lang.Class are used only when particular
operations are applied to a class, such as reflection, annotation
accesses, and class redefinition (via JVMTI).
Moving these fields to a separate helper class could reduce the size of
Class objects when those fields are not needed. Conversely, however, it
must be noted that if any of the fields are needed then we not only need
to restore the same effective object size, we have added 4 bytes for the
helper reference and 8 bytes for the helper object itself.
The fields supporting reflection caching and annotations can be moved to
a helper class without impact to the VM or serialization.  The reflection
and annotation information accessors are not particularly
performance-sensitive, but the performance impact due to the indirection
should be measured and potentially mediated.
In general, moving infrequently-used fields to helper classes will reduce
allocations in the typical case but the additional indirection may have a
performance impact that must be measured and taken into consideration.
Candidate: Disable the Reflection Compiler
The reflection compiler generates bytecodes for method calls to improve
performance.  Disabling the compiler would reduce dynamic footprint.  The
performance penalty can be substantial on specially-crafted tests but is
expected to be fairly small on typical applications, which do not rely
heavily on reflection.
Candidate: Miscellaneous Memory Reductions
Other memory reductions need to be investigated by analyzing heap usage
within candidate applications.  Possible reductions include tuning the
initial sizes of internal tables, caches, and buffers to reduce wastage.
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
