On Mon, 13 Jul 2026 11:22:10 GMT, Kuai Wei <[email protected]> wrote: >> src/java.base/share/classes/jdk/internal/util/ArraysSupport.java line 154: >> >>> 152: // boundary and reach an inaccessible page. Copy exact >>> tail bytes to a temp >>> 153: // buffer to avoid out-of-bounds access. >>> 154: byte[] buff = new byte[Long.BYTES]; >> >> What's the point of messing with a temp buffer? Why can't you simply compare >> tail bytes one by one? > > 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? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/31802#discussion_r3574980587
