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

[Maurizio Cimadamore]

On Fri, 6 Aug 2021 16:21:22 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Switch order of bulk write method parameters (so that segment is always first).
>
> I was not following the whole discussion too closely, so I hope I am not going over old ground, but this is my impression of the latest patch:
> 
> - I can understand the appeal of consistently using the read/write prefixes, but I think it may be confusing. In our Java APIs these names are commonly used for serialization and input/output streams etc. For memory access it would be more consistent to use set/get for individual access and copy for bulk access, rather than biasing towards whether the memory segment is the src or dst. The location in `MemoryAccess` is fine. Overloading with `copy` is probably fine, rather than identifying in the name whether the array is src or dst.
> 
> - For the copy methods I would prefer consistency with `System.arraycopy`, where the src occurs first regardless of the type (rather than segment src or dst, and the src flipping argument position). It’s really easy to make stupid mistakes confusing src/dst and I think this could increase such mistakes.
> 
> - Expanding on the latter point arguably suggests that `MemorySegment.copyFrom` should be changed to `MemorySegment.copyInto` (or just `copy`), so the receiver is the src, and it returns the destination. Then there is the same consistency of arguments as in the other copy methods. However, that would bury the dst segment allocation as an argument rather than as the receiver, but at least i would be able to reason consistently about the src/dst offsets/lengths argument positions.

following @PaulSandoz  comments, I've reverted the names inside MemoryAccess to get/set and copy. Copy methods are now consistent with System::arrayCopy.

I have not touched copyFrom - as I think that one deserves some more discussion: I think under the objection there is a feeling that the instance method is worse, readability-wise, than a static method. If that's the case, we should just bite the bullet, drop copyFrom, and use a static MemorySegment::copy.

I'm also looking at MemorySegment::toArray as something that looks superseded now that we have better array copy facilities.

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

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