RFR: 8339531: Improve performance of MemorySegment::mismatch [v3]

[Maurizio Cimadamore]

On Thu, 5 Sep 2024 08:34:11 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to improve the performance of `MemorySegment::mismatch` by using Java code rather than transitioning to native code.
>
> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:
> 
>  - Merge branch 'master' into mismatch-performance2
>  - Move fill to SegmentBulkOperations
>  - Add system property and improve benchmark
>  - Update src/java.base/share/classes/jdk/internal/foreign/SegmentBulkOperations.java
>    
>    Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>
>  - Remove temp methods
>  - Clean up
>  - Update comment
>  - Merge branch 'master' into mismatch-performance2
>  - Create a separate class for segment bulk operations
>  - Add Java implementation of MS::mismatch

src/java.base/share/classes/jdk/internal/foreign/SegmentBulkOperations.java line 56:

> 54:     // Update the value for Aarch64 once 8338975 is fixed.
> 55:     private static final long NATIVE_THRESHOLD_FILL = powerOfPropertyOr("fill", Architecture.isAARCH64() ? 10 : 5);
> 56:     private static final long NATIVE_THRESHOLD_MISMATCH = powerOfPropertyOr("mismatch", 20);

This large threshold will cause a regression on Linux x64 for heap segments.

test/micro/org/openjdk/bench/java/lang/foreign/Mismatch.java line 87:

> 85:     }
> 86: 
> 87:     @Fork(value = 3, jvmArgsAppend = {"-Djava.lang.foreign.native.threshold.power.mismatch=31"})

Should we add similar variants to the fill benchmarks?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20848#discussion_r1745280069
PR Review Comment: https://git.openjdk.org/jdk/pull/20848#discussion_r1745277753