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

[Paul Sandoz]

Yes, add the “large” strip mining implementation to ArraysSupport. I think it unlikely this method ever needs to be made intrinsic. For large loop bounds it's important that we don’t starve the system (allow for safe points), so it’s easier to do that from Java than in the intrinsic stub or in C2.

Then the memory segment code can use the those primitives based on thresholds. I suspect it can get away with just calling the large version, after a check for a small threshold value and a scalar loop.

Paul.

> On May 20, 2020, at 8:53 AM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
> 
> 
> On 20/05/2020 16:36, Paul Sandoz wrote:
>> On Wed, 20 May 2020 14:06:48 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.
>> Very nice.
>> 
>> Improving the JDK implementation is good. In fact i think you could so that now. In `ArraysSupport`, with strip mining:
>> 
>>     public static int vectorizedMismatchLarge(
>>                                          Object a, long aOffset,
>>                                          Object b, long bOffset,
>>                                          long length,
>>                                          int log2ArrayIndexScale)
>> 
>> Then you can specialize mismatch of memory segments for length threshold and type (the threshold only really makes
>> sense for the first check, once you go over `Integer.MAX_VALUE` the cost of another round with a small length part is
>> really low overall).
> 
> To be clear - are you suggesting to add vectorizedMismatchLarge inside ArraySupport (but not add intrinsic support for that, for now) - and then to have the memory segment implementation to call either that or the standard version based on whether the segment is small or not?
> 
> Maurizio
> 
>> 
>> -------------
>> 
>> Marked as reviewed by psandoz (Committer).
>> 
>> PR: https://git.openjdk.java.net/panama-foreign/pull/180 <https://git.openjdk.java.net/panama-foreign/pull/180>