On Thu, 5 Sep 2024 08:34:11 GMT, Per Minborg <pminb...@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+mcimadam...@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
