RFR: 8338591: Improve performance of MemorySegment::copy

[Per Minborg]

On Tue, 3 Sep 2024 11:32:26 GMT, Maurizio Cimadamore <mcimadamore 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 625:
> 
>> 623:         if (size <= 0) {
>> 624:             // Do nothing
>> 625:         } else if (size < COPY_NATIVE_THRESHOLD && !src.overlaps(dst)) {
> 
> This is basically a conservative test - correct? E.g. we might end up cosidering two segments as overlapping even when they are not (because of offsets) - but that's ok, I actually think it's a good pragmatic solution.

Yes, it is conservative. We can tolerate overlaps in one direction (but not the other). We refrain from using these cases as they are unlikely, and checking would incur a performance price for all other (much more likely) cases.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20829#discussion_r1741982874