RFR: 8343789: Move mutable nmethod data out of CodeCache

[Dean Long]

On Sat, 9 Nov 2024 11:35:23 GMT, Boris Ulasevich <bulasevich at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5273:
>> 
>>> 5271:   } else {
>>> 5272:     address dummy = address(uintptr_t(pc()) & -wordSize); // A nearby aligned address
>>> 5273:     mov(dst, Address(dummy, rspec));
>> 
>> Why this is needed?
>
> - it is not a load from a Constant Pool, so calling ldr_constant here is seems incorrect
> - the ldr_constant function utilizes either ldr (with a range limit of ±1MB) or, when -XX:-NearCpool is enabled, adrp (range limit of ±2GB) followed by ldr — both of which may fall short when mutable data is allocated on the C heap.

This change looks wrong, for a number of reasons.  First, the dummy address would no longer be needed, and we could just use the same mov as the supports_instruction_patching() case.  However, if supports_instruction_patching() is false, I think we are not allowed to generate a multi-instruction movz/movk sequence.  We really need something like ldr_constant for this case, so that we load from memory.
However, as you point out, this is tied to NearCpool.  For a far metadata slot access, ADR+LDR is the right answer.  After this change, will there be any metadata left that could still benefit from NearCpool?   If not, then it might make sense to turn it off permanently.  Instead of choosing between PC-relative "ldr literal" and far ADR+LDR based on NearCpool, we could decide based on the distance to the metadata table. I believe "ldr literal" only has a 1MB range.
CC @theRealAph

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21276#discussion_r1853197113