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

Andrew Dinn adinn at openjdk.org
Mon Jul 14 21:11:38 UTC 2025


On Mon, 14 Jul 2025 17:29:11 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Correction. It is true for G1, Z, Shenandoah. For others we still have constant in C2 IR

Ok, so for Leyden premain we really need to detect a card table base ConP in an x86 C2 graph and generate an external reloc for it -- if, say, we use a generational serial/parallel GC. Likewise we will need to detect and generate external relocs for any ConP node that references an AOTRuntimeConstants field. 

We don't have to do it using a matching rule. We could instead implement the relevant logic in the encoding for a generic load(ConP) rule or in a macro assembler method called from that encoding.

I still personally prefer the idea of distinguishing the relevant cases by detecting a RawPtr vs an OopPtr as being the least intrusive. However, as you say that may still leave us with a card base address that might cause other problems (e.g. it might be zero or a small negative offset). So, let's deal with the backports as Alexei proposed and, when we come to it, implement the premain variants in the encoding or macro assembler rather than via match rules.

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

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


More information about the hotspot-compiler-dev mailing list