On Wed, 8 Jul 2026 02:41:29 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.
>
>> the changes to current JDK call sites are merely simplifications that take
>> advantage of the stronger guarantee.
>
> How do you get stronger guarantees? Is it based solely on
> implementation-specific observations that the intrinsics always perform full
> scan over the arrays? If `ArraysSupport.vectorizedMismatch()` is allowed to
> perform partial comparison by the spec (and report non-zero count of
> remaining elements), then I don't see how you can drop the check at call
> sites.
Hi @iwanowww, I think the spec can remain unchanged. The current spec does not
limit a full scan or a partial scan — this is implementation-dependent. So
the proposal is simply to align the Java fallback implementation with the
existing x86_64 intrinsic behavior, making them consistent without any spec
changes. How do you think about it ?
-------------
PR Comment: https://git.openjdk.org/jdk/pull/31802#issuecomment-4911095530
