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

[Boris Ulasevich]

On Mon, 2 Dec 2024 22:20:04 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Boris Ulasevich has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   rework movoop for not_supports_instruction_patching case: correcting in ldr_constant and relocations fixup
>
> 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));
    }
  }

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

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