RFR: 8338591: Improve performance of MemorySegment::copy
Maurizio Cimadamore
mcimadamore at openjdk.org
Tue Sep 3 15:47:23 UTC 2024
On Tue, 3 Sep 2024 11:51:57 GMT, Francesco Nigro <duke at openjdk.org> wrote:
>> This PR proposes to handle smaller FFM copy operations with Java code rather than transitioning to native code. This will improve performance. In this PR, copy operations involving zero to 63 bytes will be handled by Java code.
>>
>> Here is what it looks like for Windows x64:
>>
>> 
>>
>> Here is another chart for Linux a64:
>>
>> 
>>
>> Other platforms exhibit similar behavior. It should be noted that the gain with this PR is pronounced for certain common sizes that are more likely to appear in code (e.g. 8, 16, 24, and 32)
>>
>> It would be possible to use the same code path for the 7arg `MemorySegment::copy` method if it is similar to:
>>
>>
>> MemorySegment.copy(heapSrcSegment, JAVA_BYTE, 0, heapDstSegment, JAVA_BYTE, 0, ELEM_SIZE);
>>
>>
>> This could be added in a separate PR.
>>
>> This PR has been tested with tier1-3 and passed.
>
> src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java line 642:
>
>> 640: // 0...0X00
>> 641: if (remaining >= 4) {
>> 642: final int v = SCOPED_MEMORY_ACCESS.getInt(src.sessionImpl(), src.unsafeGetBase(),src.unsafeGetOffset() + srcOffset + offset);
>
> src.sessionImpl() worth being hoisted out once? It's a minor thing eh -same for `dst` and base/offsets
tried that - and it's mostly a wash. For `unsafeGetBase` some care is required - that method contains a cast to the sharp array type that is backing the segment (if the segment is on-heap). This cast is crucial to inform the `Unsafe` intrinsics on the type of the array being operated on. If `Unsafe` doesn't know that type it falls back to a slower intrinsics. So better to keep that where it is.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/20829#discussion_r1742294091
More information about the core-libs-dev
mailing list