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

Andrew Haley aph at openjdk.org
Tue Jul 15 08:22:40 UTC 2025


On Mon, 14 Jul 2025 15:36:41 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> On x86 byte_map_base is handled in GC code: https://github.com/openjdk/leyden/blob/premain/src/hotspot/cpu/x86/gc/g1/g1BarrierSetAssembler_x86.cpp#L314 https://github.com/openjdk/leyden/blob/premain/src/hotspot/cpu/x86/gc/shared/cardTableBarrierSetAssembler_x86.cpp#L67
> 
> Using relocation for byte_map_base is not safe (see comment in `g1BarrierSetAssembler_x86.cpp`). We are "safe" because we bailout AOT code caching if byte_map_base is not relocatable: https://github.com/openjdk/leyden/blob/premain/src/hotspot/share/code/aotCodeCache.cpp#L338

Here:


 // Do not use ExternalAddress to load 'byte_map_base', since 'byte_map_base' is NOT
  // a valid address and therefore is not properly handled by the relocation code.
  if (AOTCodeCache::is_on_for_dump()) {
    // AOT code needs relocation info for this address
    __ lea(tmp2, ExternalAddress((address)ct->card_table()->byte_map_base()));   // tmp2 := card table base address
  } else {


It says "Do not use `ExternalAddress` to load 'byte_map_base'" but then uses `ExternalAddress`. I'm baffled...

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

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


More information about the hotspot-compiler-dev mailing list