[foreign-memaccess+abi] RFR: 8290880: Add static MemorySegment::mismatch method

[Paul Sandoz]

On Fri, 22 Jul 2022 15:50:57 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 2015:
>> 
>>> 2013:      * @see MemorySegment#mismatch(MemorySegment)
>>> 2014:      */
>>> 2015:     static long mismatch(MemorySegment srcSegment, long srcOffset, MemorySegment dstSegment, long dstOffset, long bytes) {
>> 
>> Should we make the signature the same as that for Arrays.mismatch e.g.:
>> 
>>     public static int mismatch(byte[] a, int aFromIndex, int aToIndex,
>>                                byte[] b, int bFromIndex, int bToIndex) {
>> 
>> ?
>> It's tempting to make both mismatch methods static.
>
> Note that `Arrays.mismatch` seems to compute the `length` of the mismatch using some fixed formula, and then calls `ArraysSupport::vectorized` mismatch with a single length parameter. So it seems to me that a version that accepts a `length` parameter is "more primitive" (users can then fill with what they want).
> 
> As for making "both" methods static, I assume you mean `MemorySegment::mismatch` (the instance method). While doable, the same argument applies to `copyFrom`. I think we settled to have both variants as they will likely be used in different ways.

Re: static vs instance, apologies I don't mean to reopen that discussion.

IIRC the motivation for the signatures in `Arrays` was in part because that is the pattern used by all the other methods. You are right that the underlying primitive is passing in a common length, which is what the supporting internal mismatch methods use, but it may not be as helpful to require the user to compute the minimum length. To be honest I am torn between keeping close to the `copy` signature or using absolute ranges :-)

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

PR: https://git.openjdk.org/panama-foreign/pull/691