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

[Andrew Haley]

On Tue, 15 Jul 2025 11:21:29 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

> > It says "Do not use ExternalAddress to load 'byte_map_base'" but then uses ExternalAddress. I'm baffled...
> 
> You need to read it as a FIXME ;-)

Aha!

> The current workaround that we have prototyped is to place the base 'address' in a field in the global AOTRuntimeConstants instance and load it via that field. That's not very attractive because we need to do an indirect load from an lea'd constant address (movz/movk/movk/ldr) at every occurrence of a GC barrier. We also need to relocate every mov sequence when we load the code from the archive.

Eww.

> What we would like longer term is to store the address in a method/stub's constants section and use a pc-relative load to access it.

IMHO that doesn't help very much. You're still looking at ~4 cycles to load from L1 dcache, and you kill a dcache line for it, and you consume a full xword of code space for it. If we put the byte-map base on a 32-bit boundary we only need a single MOVZ, and that can be relocated easily enough when we load the code from the archive. Surely that's better. Or is even that small work too much?

We would need to provide the constant entry with a relocation so we can reinit it to the VM's current base at AOT code load but we can use the same constant for every occurrence of the barrier. That also means we update less pages during reloc which means we should eventually be able to rely on mmaping AOT cocde cache pages with limited copy on write for reloced insns.

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

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