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

[Maurizio Cimadamore]

On Wed, 20 May 2020 18:18:49 GMT, Chris Hegarty <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