On Thu, 16 Jul 2026 04:27:05 GMT, Kuai Wei <[email protected]> wrote: >> I recently noticed a behavioral discrepancy in >> jdk.internal.util.ArraysSupport.vectorizedMismatch between the Java >> implementation and the platform intrinsic implementations. >> >> Current behavior >> >> The Java implementation may leave a tail of elements unchecked, returning >> the bitwise complement of the number of remaining elements (i.e., >> ~remaining). >> The x86_64 intrinsic, by contrast, compares all elements and simply returns >> -1 when no mismatch is found. >> >> Proposed change >> >> This PR refines the Java implementation so that it always compares all >> elements and returns -1 when no mismatch is found, matching the x86_64 >> intrinsic behavior. >> >> A regression test is included at >> `test/hotspot/jtreg/compiler/intrinsics/VectorizedMismatchReturnDiffTest.java` >> which demonstrates the original behavioral difference. >> >> ## Test >> - [x] tier1 test suites on linux x86_64 >> - [x] tier1 test suites on linux aarch64 >> >> --------- >> - [x] I confirm that I make this contribution in accordance with the >> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). > > Kuai Wei has updated the pull request incrementally with two additional > commits since the last revision: > > - Fix indent > - Recovery comments
Sorry for the late response — I was occupied with other tasks last week. After reviewing the discussion, I'd like to summarize the current direction: introduce a private intrinsic method that retains the origin contract (allowing partial processing), and wrap it with `ArraysSupport.vectorizedMismatch` as a public-facing wrapper. The wrapper will handle any remaining tail data in Java, ensuring all elements are fully compared before returning. This way, intrinsics on different architectures are free to perform partial work (returning ~remaining), while the wrapper guarantees that callers always receive either a mismatch index (>= 0) or -1. Accordingly, all existing call sites will be updated to remove their tail-handling logic, since the wrapper now takes care of that centrally. ------------- PR Comment: https://git.openjdk.org/jdk/pull/31802#issuecomment-5179573781
