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

[Dean Long]

On Tue, 10 Dec 2024 22:31:05 GMT, Boris Ulasevich <bulasevich at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp line 1423:
>> 
>>> 1421:     } else {
>>> 1422:       uint64_t offset;
>>> 1423:       adrp(dest, const_addr, offset);
>> 
>> I don't see how this ADRP path ever gets called now.  The only caller is in MacroAssembler::movoop(), which uses a dummy Address in the CodeCache.  I think we need to force near/far with an extra bool parameter.  The way this function is currently used, a better name might be ldr_patchable().
>
> Thanks for pointing that out. I reworked the method a little.
> 
> ldr_patchable() is only called by movoop(). If oops is moved to a separate location, the distance is certainly > 1MB and adrp+ldr is the only way to access oops. The single LDR path is not used now, but I leave it for future use.
> 
> 
>   void ldr_patchable(Register dest, const Address &const_addr, bool fits_in_ldr_range = false) {
>     if (fits_in_ldr_range) {
>       intptr_t offset = pc() - const_addr.target();
>       assert(offset >= -1024 * 1024, offset < 1024 * 1024, "pointer does not fit into pc-relative ldr range")
>       ldr(dest, const_addr);
>     } else {
>       uint64_t offset;
>       adrp(dest, const_addr, offset);
>       ldr(dest, Address(dest, offset));
>     }
>   }

The problem with leaving "fits_in_ldr_range" in for future use is that it hasn't been tested.  I suggest just removing it.  It uses pc() instead of the codecache boundaries to decide the range, so it only works for code that isn't relocated.

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

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