On Tue, 3 Sep 2024 07:52:44 GMT, Per Minborg <pminb...@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 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20829#discussion_r1741922136
