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
> 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. So, indeed the implementation will now _always_ process all elements? i.e. as Chen says, the only negative number the implementation will now return is `-1`? In that case, I think the spec should be updated, and users should be simplified. I think it's bad to leave code that deals with the tail around when it's not needed in practice (it will just bit rot). > Unless ArraysSupport.vectorizedMismatch() guarantees all elements are > processed on successful match, I don't see how you can make such change . @iwanowww Do you see a problem with changing the spec? This is an internal API, so updating the spec is relative pain free. It would certainly simplify call sites of this method. ------------- PR Comment: https://git.openjdk.org/jdk/pull/31802#issuecomment-4994271284
