[foreign-memaccess+abi] RFR: 8270376: Finalize API for memory copy [v14]

[Maurizio Cimadamore]

On Tue, 10 Aug 2021 09:32:09 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This patch ties up some loose ends with the MemoryCopy API, and it also prepares the ground for some other related refactorings in this area.
>> 
>> The meat of this patch is represented by the various changes in MemoryCopy, where all methods were renamed to simply `copy`, and the length parameter (now called `elementCount`) is always moved to the end.
>> 
>> I've also simplified naming of parameters, as I think distinguishing between `index` and `offset` is enough (e.g. an array has an index, a segment has an offset).
>> 
>> You will see that, at the very end of the class, three more copy methods have been added, which deal fully in terms of segments. I have also moved the complex layout-based memory segment copy operation (which does the swap) as a static method in this class, as I believe the static form makes the method more regular and usable.
>> 
>> I've made some changes to our uses of `copyFrom` in the linker, to use the new methods in `MemoryCopy` when the copy operation was performing slicing in the source/target segment, which I think makes the code more readable. Of course these changes are completely optional and could be omitted as well.
>
> Maurizio Cimadamore has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Tweak micro benchmarks
>  - Improve performance of generic copy methods

While the latest API still looks good - it occurred to me that if we want to do anything in MemoryAccess::copy which e.g. for small copy sizes bypasses the bulk copy and just does a for loop, having all the copy overloads merged into one could be problematic (because of pollution). That said, the threshold for switching copy mechanism in the ByteBuffer API is set at 6 bytes (!!) - which is very low (e.g. 1.5 ints). So I'm not sure how much that logic is really needed (especially since now `Unsafe.memoryCopy` is a VM intrinsic). That said, if, one day, we'd like to rewrite those routines in Java, using memory access API + vector API, using an opaque object carrier can definitively be an issue (the vector API also likes to be sharp in its carrier type).

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

PR: https://git.openjdk.java.net/panama-foreign/pull/568