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

[Andrew Dinn]

On Tue, 15 Jul 2025 12:42:02 GMT, Andrew Haley <aph at openjdk.org> wrote:

> Is anyone trying to load AOT blobs at a fixed address?

That's not really a good idea for security. However, even if we did we would still need AOT code to refer to external symbols that may be at different locations in the Assembly (AOT compile) VM and production VM. In particular the BMB varies depending on where the card table and heap base are located, both determined by runtime allocations.

n.b. it is important to note that BMB is not the base of the table. It is a pre-offset variant on that base address, computed by adding (card table base - heap base) >>  log(card table granularity). As you are no doubt aware, a pre-offset address constant avoids the need for the barrier to do anything but shift a heap pointer down and add it to BMB to compute the associated card address.

That explains why ConP(BMB) is problematic. It is not -- as often stated -- because the value is not an address (offseting an address by a constant still gives an address). The problem is rather what value that address might have. Depending on where the two regions are placed it could actually be, say,  ConP(0) or some other ConP that we want to treat specially (especially a ConP in the oop range).

> If C2 can be persuaded to treat the BMB as a value to be propagated like any other value then all of this conversation effectively becomes a don't care. Except for legacy architectures with insufficient registers, of course...

In principle that can already happen when the BMB is inserted into a C2 graph as a ConP -- although I have never seen it actually occurring. However, we have recently migrated barrier insertion to the back end for G1, Shenanadoah and ZGC, So, there is no opportunity for the compiler to perform constant elision in those three cases. The only GCs for which a ConP(BMB) is currently inserted into the graph are (generational) Serial/Parallel.

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

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