RFR: 8361892: AArch64: Incorrect matching rule leading to improper oop instruction encoding [v2]

Andrew Dinn adinn at openjdk.org
Mon Jul 14 11:10:39 UTC 2025


On Mon, 14 Jul 2025 09:40:37 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Wait, but only AArch64/RISC-V have immByteMapBase, so I presume other platforms deal with the need to record relocation for card table base through some other means? With special immByteMapBase removed, would the same way work for AArch64?

I'm not sure how this works for the byte_map_base on x86. I just looked thorugh the x86 premain code and I cannot find any special case handling for it. 

However, on both x86 and aarch64 we also use immediate ConP operand rules to inject relocs for constant addresses that refer to entries in the (global) AOT Runtime Constants area. So, this is another case similar to byte_map_base where we AOT compilation needs to recognize a special address and handle ir appropriately. Here are the x86 rules for AOT Constant addressses

// AOT Runtime Constants Address
operand immAOTRuntimeConstantsAddress()
%{
  // Check if the address is in the range of AOT Runtime Constants
  predicate(AOTRuntimeConstants::contains((address)(n->get_ptr())));
  match(ConP);

  op_cost(0);
  format %{ %}
  interface(CONST_INTER);
%}
. . .
instruct loadAOTRCAddress(rRegP dst, immAOTRuntimeConstantsAddress con)
%{
  match(Set dst con);

  format %{ "leaq  $dst, $con\t# AOT Runtime Constants Address" %}

  ins_encode %{
    __ load_aotrc_address($dst$$Register, (address)$con$$constant);
  %}

  ins_pipe(ialu_reg_fat);
%}

The referenced macro assembler method is defined as follows

void MacroAssembler::load_aotrc_address(Register reg, address a) {
#if INCLUDE_CDS
  assert(AOTRuntimeConstants::contains(a), "address out of range for data area");
  if (AOTCodeCache::is_on_for_dump()) {
    // all aotrc field addresses should be registered in the AOTCodeCache address table
    lea(reg, ExternalAddress(a));
  } else {
    mov64(reg, (uint64_t)a);
  }
#else
  ShouldNotReachHere();
#endif
}

I'm not sure whether the latest premain code is just in flux and does not yet deal with byte_map_base on x86 or whether there is some other mechanism. Perhaps @ashu-mehra or @vnkozlov can clarify.

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

PR Comment: https://git.openjdk.org/jdk/pull/26249#issuecomment-3069024341


More information about the hotspot-compiler-dev mailing list