On Mon, 13 Jul 2026 23:28:53 GMT, Vladimir Ivanov <[email protected]> wrote:
>> The intent is to load all remaining tail bytes into a single long word and >> compare them in one operation. The temp buffer is used to ensure safe memory >> access. If the allocation overhead is a concern, I can switch to a >> byte-by-byte loop. > > IMO it's an overkill and it has severe performance implications. Since > non-intrinsified version is used everywhere except x86, I wouldn't be > surprised if it turns out to be performance sensitive. > > As I see it, JDK-8136924 tried to optimize it for non-intrinsified case by > performing bulk comparion in generic manner and then do tail processing in > specialized versions. You propose to eliminate specialized tail processing > and do everything in generic version, but copy data first to avoid OOB > accesses. > > If you still want to process the tail in generic version, I'd suggest to > leave existing tail processing (single `Unsafe.getInt` load) as is and add > byte comparisons for remaining 3 bytes (at most). (In the worst case, single > char/short comparison becomes 2 byte ones.) > > But now I'd like to question the benefits of the refactoring as a whole: > specialized versions still fallback to scalar comparison for small arrays. > Why bother with exhaustive tail processing in generic version then? Thanks for the suggestion on tail processing. The primary goal of this PR is to ensure behavioral consistency between the Java implementation and the x86_64 intrinsic. I agree that performance is also a key consideration here. I've updated the tail processing to use an `Unsafe.getIntUnaligned` followed by a byte-by-byte loop for the remaining bytes. Compared to the original implementation, the only addition is a small loop handling up to 3 remaining bytes. IMO, the performance overhead is limited. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/31802#discussion_r3578375219
