On Tue, 8 Sep 2026 12:24:05 GMT, Andrew Haley <[email protected]> wrote:

>> Ehsan Behrangi has updated the pull request with a new target base due to a 
>> merge or a rebase. The pull request now contains five commits:
>> 
>>  - Merge remote-tracking branch 'openjdk/master' into 
>> array_hashcode_conflict_fix
>>    
>>    # Conflicts:
>>    # test/jdk/java/util/Arrays/HashCode.java
>>  - Improve intrinsic test coverage for ArraysSupport.vectorizedHashCode
>>  - Address review comment
>>  - 8385513: AArch64: Improve ArraysSupport.vectorizedHashCode performance 
>> for large arrays
>>    
>>    The current AArch64 implementation of ArraysSupport.vectorizedHashCode
>>    processes polynomial reductions in relatively small groups, which limits
>>    parallelism in the hash accumulation path for large arrays.
>>    
>>    This change increases polynomial batch size to 16-element groups using a
>>    larger precomputed powers-of-31 table. The updated implementation enables
>>    more independent multiply operations and reduces dependency chains in the
>>    main hashing loop.
>>    
>>    The optimization also reduces generated stub size for all supported
>>    element types, lowering instruction cache pressure in hot hashing
>>    workloads.
>>    
>>    The optimization applies to boolean[], byte[], char[], short[], and
>>    int[] array hashing paths and is enabled only for array lengths >= 8.
>>    Shorter arrays continue to use the existing scalar implementation.
>>    
>>    Generated stub size reduction:
>>    | Element type | New size | JDK 25 size | Reduction |
>>    | ------------ | -------- | ----------- | --------- |
>>    | boolean      | 332 B    | 428 B       | -96 B     |
>>    | byte         | 332 B    | 428 B       | -96 B     |
>>    | char         | 332 B    | 408 B       | -76 B     |
>>    | short        | 332 B    | 408 B       | -76 B     |
>>    | int          | 300 B    | 324 B       | -24 B     |
>>    
>>    ----------------------------------------------------
>>    BYTE[] Arrays.hashCode throughput (ops/ms):
>>    Lengths below 8 use the existing scalar path and are therefore expected 
>> to show no meaningful change.
>>    
>>    | Length | Baseline | New    | Improvement |
>>    |--------|----------|--------|-------------|
>>    | 2      | 696842   | 681572 | -2.2%       |
>>    | 7      | 349082   | 349392 | +0.1%       |
>>    | 8      | 309193   | 395677 | +28.0%      |
>>    | 9      | 294240   | 367510 | +24.9%      |
>>    | 15     | 160372   | 202718 | +26.4%      |
>>    | 16     | 241651   | 348854 | +44.4%      |
>>    | 17     | 228929   | 308820 | +34.9%...
>
> src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 10357:
> 
>> 10355:       case T_SHORT:   elem_bytes = 2; widen_signed = true;  break;
>> 10356:       case T_INT:     elem_bytes = 4; widen_signed = false; break;
>> 10357:       default:        ShouldNotReachHere();
> 
> Suggestion:
> 
>       elem_bytes = type2aelembytes(eltype);
>       widen_signed = is_signed_subword_type(eltype);

Thank you, fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/31674#discussion_r3958384255

Reply via email to