On Tue, 3 Sep 2024 11:51:57 GMT, Francesco Nigro <d...@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
