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

[Stefan Karlsson]

On Fri, 24 Jan 2025 20:37:32 GMT, Boris Ulasevich <bulasevich at openjdk.org> wrote:

>> 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 incrementally with one additional commit since the last revision:
> 
>   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

Changes requested by stefank (Reviewer).

src/hotspot/share/code/nmethod.cpp line 2162:

> 2160:     return nullptr;
> 2161:   }
> 2162:   return RawAccess<>::oop_load(oop_addr_at(index));

This change is removing the GC barriers and is likely the cause of the ZGC crash that Tobias listed.

However, the fix is not as simple as to just reinstate the NMethodAccess call. The ZGC code uses the `oop*` to find the associated `nmethod` in the code cache. We need another way to fetch the nmethod now. So, I'm experimenting with a small change to switch out the Access API call to a direct GC barrier set call and then I pass down the `this` pointer from this function. With that you should be able skip this change.

With that said, what was the motivation for changing this?

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

PR Review: https://git.openjdk.org/jdk/pull/21276#pullrequestreview-2589786147
PR Review Comment: https://git.openjdk.org/jdk/pull/21276#discussion_r1939317498