On Tue, 7 Jul 2026 18:29:14 GMT, Vladimir Ivanov <[email protected]> wrote:
> ArraysSupport.vectorizedMismatch JavaDoc says the following:
>
> ```
> * @return if a mismatch is found a relative index, between 0 (inclusive)
> * and {@code length} (exclusive), of the first mismatching pair of
> elements
> * in the two arrays. Otherwise, if a mismatch is not found the bitwise
> * compliment of the number of remaining pairs of elements to be checked
> in
> * the tail of the two arrays.
> ```
>
> Unless you change the contract (so it is mandated to check all elements), I
> don't see how you can simplify checks at call sites.
>
> But another question is do we really want to do so? It forces intrinsics on
> all platforms to fully process input arrays which may introduce unnecessary
> complexity. Alternatively, you can introduce a wrapper which handles tail
> processing in Java.
Thanks for the review. A couple of clarifications:
The proposed change does not break the existing contract. If all elements are
checked and no mismatch is found, returning -1 is fully consistent with the
current JavaDoc specification. Existing call sites continue to work correctly
without any modification — the changes to current JDK call sites are merely
simplifications that take advantage of the stronger guarantee.
In practice, x86_64 is the only platform that provides an intrinsic for this
method today, and it already processes all elements. I noticed this behavioral
discrepancy while working on a RISC-V intrinsic for it. From the RISC-V
perspective, scanning all elements is actually the simpler approach to
implement.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/31802#issuecomment-4910792420
