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
What John said. >From JVM perspective, the current API contract is the optimal one. It leaves >enough freedom for the JVM to choose between completeness and simplicity. Even >though on x86 (and AFAIU RISC-V in the future) the choice was made in favor of >completeness, it doesn't mean all other platforms would do the same. The only downside of keeping the existing API is that "<-1" case is left untested. I'm in favor of keeping the API as it is, but if others are strongly in favor of forbidding "<-1" return values I'm fine with changing it. Since the API is internal, the change can be reverted if needed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/31802#issuecomment-5063280642
