RFR: 8361892: AArch64: Incorrect matching rule leading to improper oop instruction encoding
Yadong Wang
yadongwang at openjdk.org
Sat Jul 12 06:17:49 UTC 2025
On Fri, 11 Jul 2025 12:40:40 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:
> It is such a beautiful bug to read about on Friday.
>
> So the net effect of this mismatch is that we miss oop relocation/record when `ConP` accidentally mismatches to card table base, did I get that right?
>
> > Yes, it maybe a better solution for jdk main line, because immPollPage was remove in https://bugs.openjdk.org/browse/JDK-8220051. But how about jdk8u backport?
>
> I think we should do these things separately:
> 1. `immByteMapBase` rule removal in AArch64, this PR, then backport it to 25, 21, 17, maybe to 11, 8
> 2. `immByteMapBase` rule removal in RISC-V, separate PR, then backport it to 25, 21
> 3. `immPollPage` rule removal in AArch64, in 11u and 8u specific PRs, _IF_ we think that is a problem, which I don't think it is.
>
> The backports for (1) would not be clean, as Generational Shenandoah barrier checks would likely trigger technical conflicts in the code that is being removed. So there is doubly no point in going for clean backports, we should really slice them by the rule we are removing.
Agree, very clear strategy. l'll just remove the bytemapbase rule in this pr and do enough tests.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/26249#issuecomment-3064755489
More information about the hotspot-compiler-dev
mailing list