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:
>> 
>> ![image](https://github.com/user-attachments/assets/6b31206e-3b24-4b34-bf38-a1be393186d3)
>> 
>> Here is another chart for Linux a64:
>> 
>> ![image](https://github.com/user-attachments/assets/b679bfac-670a-42a5-802b-2b17adf5ec79)
>> 
>> 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