On Fri, 17 Apr 2026 09:35:56 GMT, Paul Hübner <[email protected]> wrote:
> Hi all, > > This fixes implementation bugs in the interpreter and C1 for `if_acmp<cc>` > bytecodes. > > The substitutability check that we perform to determine equality of value > objects requires that certain conditions have been checked beforehand. > Namely, that it's not the same object, neither is null, and both are value > objects with the same klass. > > At the point of the null-check, it is already clear that the oops are > unequal; hence the nullcheck checks `lhs == 0 xor rhs == 0`. Both the AArch64 > interpreter and x86 C1 code falsely ANDs the two operands. This can yield > false positives if two oops have no set-bit positions in common (e.g., `1010` > and `0101`). The operands need to be compared separately; the interpreter for > x86 and C1 for AArch64 already does this. > > Note that this fix is covered by the many test cases failing in > `compiler/valhalla/inlinetypes/`. > > Testing: tiers 1-4 on Linux (x64, AArch64), macOS (x64, AArch64), Windows > (x64). > > --------- > - [x] I confirm that I make this contribution in accordance with the [OpenJDK > Interim AI Policy](https://openjdk.org/legal/ai). Shouldn't the title be about "false negatives"? We mistakenly assume that `x == 0 || y == 0` is equivalent to `(x & y) == 0`. However, there are cases when `x != 0` and `y != 0` but `(x & y) == 0`. This means that we mistakenly take the path `x == 0 || y == 0`, which leads to `acmp` mistakenly returning `false`. Edit: My mistake, just ignore :) ------------- PR Comment: https://git.openjdk.org/valhalla/pull/2329#issuecomment-4269201659
