[foreign-memaccess] [Rev 02] RFR: Add MemorySegment::mismatch

[Paul Sandoz]

If the two segments are are different lengths and one segment is a proper prefix of the other (all elements are equal) there is a mismatch in the length. It’s described more formally in the JavaDoc of the Arrays.mismatch methods. e.g 

* <p>If the two arrays share a common prefix then the returned index is the
* length of the common prefix and it follows that there is a mismatch
* between the two elements at that index within the respective arrays.
* If one array is a proper prefix of the other then the returned index is
* the length of the smaller array and it follows that the index is only
* valid for the larger array.
* Otherwise, there is no mismatch.

Paul.

> On May 20, 2020, at 4:04 PM, Maurizio Cimadamore <mcimadamore at openjdk.java.net> wrote:
> 
> On Wed, 20 May 2020 18:18:49 GMT, Chris Hegarty <chegar at openjdk.org <mailto:chegar at openjdk.org>> wrote:
> 
>>> Hi,
>>> 
>>> As part of feedback on the Foreign Memory API (when experimenting with its usage internally in the JDK), a small number
>>> of potential usability enhancements could be made to the API. This is the fourth such, and last on my current todo
>>> list.  This change proposes to add a new method:
>>> MemorySegment::mismatch
>>> 
>>> The mismatch semantic is very useful for building equality and comparison logic on top of segments. I found that I
>>> needed such when modeling and comparing native socket address in the JDK implementation. It is possible to write your
>>> own, but requires a non-trivial amount of not-trivial code - to do it right! I also think that we can provide a more
>>> efficient implementation building on top of the JDK's internal mismatch support.  I still need to do some perf testing
>>> and add a micro-benchmake ( Maurizio suggested possibly amending TestBulkOps ). There is also the question about
>>> possibly improving the JDK's internal implementation to work on long sizes (which could be done separately). For now, I
>>> just want to share the idea, along with the proposed specification and initial implementation.  Comments welcome.
>> 
>> Chris Hegarty has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev
>> excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since
>> the last revision:
>> - Integrate Paul's review comment
>> - Merge remote-tracking branch 'origin/foreign-memaccess' into mismatch
>> - Move implementation into vectorizedMismatchLarge, and address other review comments.
>> - Initial mismatch implementation
> 
> Looks good
> 
> src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java line 170:
> 
>> 169:         }
>> 170:         return thisSize != thatSize ? length : -1;
>> 171:     }
> 
> I guess I'm a bit confused - shouldn't this method return (as per javadoc), `-1` if there's no mismatch?  In this code
> path we found no mismatch, and yet, if sizes are different we return `length`, suggesting there's a mismatch. I now
> realize that *mismatch* is taken quite literally - e.g. no mismatch really means the two things are identical in
> contents and size --- which is, I realize, what `Arrays::mismatch` also does.
> 
> IMHO the javadoc of the various `mismatch` routines could use more clarity around what a *mismatch* is. But maybe
> that's something for another day.
> 
> -------------
> 
> Marked as reviewed by mcimadamore (Committer).
> 
> PR: https://git.openjdk.java.net/panama-foreign/pull/180 <https://git.openjdk.java.net/panama-foreign/pull/180>