RFR: 8343789: Move mutable nmethod data out of CodeCache [v13]

Boris Ulasevich bulasevich at openjdk.org
Thu Feb 27 14:31:31 UTC 2025


> This change relocates mutable data (such as relocations, oops, and metadata) from the nmethod. The change follows the recent PR #18984, which relocated immutable nmethod data from the CodeCache.
> 
> The core idea remains the same: use the CodeCache for executable code while moving additional data to the C heap. The primary motivations are improving security and enhancing code density.
> 
> Although performance is not the main focus, testing on AArch64 CPUs, where code density plays a significant role, has shown a 1–2% performance improvement in specific scenarios, such as the CodeCacheStress test and the Renaissance Dotty benchmark.
> 
> The numbers. Immutable data constitutes **~30%** on the nmehtod. Mutable data constitutes **~8%** of nmethod. Example (statistics collected on the CodeCacheStress benchmark):
> - nmethod_count:134000, total_compilation_time: 510460ms
> - total allocation time malloc_mutable/malloc_immutable/CodeCache_alloc: 62ms/114ms/6333ms,
> - total allocation size (mutable/immutable/nmentod): 64MB/192MB/488MB
> 
> Functional testing: jtreg on arm/aarch/x86.
> Performance testing: renaissance/dacapo/SPECjvm2008 benchmarks.
> 
> Alternative solution (see comments): In the future, relocations can be moved to _immutable_data.

Boris Ulasevich has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:

 - cleanup
 - returning oops back to nmethods. jtreg: Ok, performance: Ok. todo: cleanup
 - Address review comments: cleanup, move fields to avoid padding, fix CodeBlob purge to call os::free, fix nmethod::print, update Layout description
 - add a separate adrp_movk function to to support targets located more than 4GB away
 - Force the use of movk in combination with adrp and ldr instructions to address scenarios
   where os::malloc allocates buffers beyond the typical ±4GB range accessible with adrp
 - Fixing TestFindInstMemRecursion test fail with XX:+StressReflectiveCode option:
   _relocation_size can exceed 64Kb, in this case _metadata_offset do not fit into int16.
   Fix: use _oops_size int16 field to calculate metadata offset
 - removing dead code
 - a bit of cleanup and addressing review suggestions
 - rework movoop for not_supports_instruction_patching case: correcting in ldr_constant and relocations fixup
 - remove _code_end_offset
 - ... and 4 more: https://git.openjdk.org/jdk/compare/3c9d64eb...56c0cc78

-------------

Changes: https://git.openjdk.org/jdk/pull/21276/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21276&range=12
  Stats: 197 lines in 7 files changed: 87 ins; 37 del; 73 mod
  Patch: https://git.openjdk.org/jdk/pull/21276.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21276/head:pull/21276

PR: https://git.openjdk.org/jdk/pull/21276


More information about the hotspot-compiler-dev mailing list