On Tue, 7 Jul 2026 10:09:48 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.
>> Because of this inconsistency, every caller has to handle the "remaining
>> elements" case defensively:
>>
>>
>> int i = vectorizedMismatch(...);
>> if (i >= 0) {
>> return i; // mismatch found
>> } else {
>> length -= ~i; // fall through to handle remaining elements
>> }
>>
>> 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. This also simplify all callsite because it eliminates
>> the need for callers to handle remaining elements.
>>
>> 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 one additional
> commit since the last revision:
>
> recover some comments
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.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/31802#issuecomment-4907174599
