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

[Boris Ulasevich]

On Fri, 22 Nov 2024 02:21:01 GMT, Dean Long <dlong at openjdk.org> wrote:

>> - 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

That's right. Thanks for pointing that out to me.
I have a fix for movoop issue on supports_instruction_patching=false case. Probably it should be considered as a separate change: https://github.com/openjdk/jdk/pull/22448

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

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