Array equality, comparison and mismatch

[Chris Hegarty]

Paul,

On 22/09/15 17:30, Paul Sandoz wrote:
> Hi,
>
> Please review the following which adds methods to Arrays for performing equality, comparison and mismatch:
>
>    https://bugs.openjdk.java.net/browse/JDK-8033148
>    http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8033148-Arrays-lexico-compare/webrev/
>    http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8033148-Arrays-lexico-compare/specdiff/overview-summary.html

This looks very good.

I know that there has been some discussion already about the behavior 
when passed null, but it seems a little unfortunate that the range 
accepting 'equals' methods don't behave in a similar manner to that of 
the non-range 'equals' methods. But I do accept that it makes little 
sense, where would the from/to indices come from. So I think NPE makes 
sense for these.

It was not immediately obvious to me that the common prefix can be 0. 
Should this be called out specifically?

Minor typo(s):

   "...the length of the smaller array and it follows THAT the
    index is only valid ..."

   "If one array is a proper prefix of the other, over the specified
    ranges, then the returned relative index is the length of the
    smaller range and it follows THAT the relative index is only valid
    for the array with the larger range."

> The motivation behind this is the use of Unsafe in popular libraries and frameworks to speed up the lexicographical comparison of byte arrays.
>
> This issue focuses on the API and functional implementations. A follow up issue [1] tracks updating the implementations to use a common method that leverages Unsafe to improve performance. A further issue [2] tracks the intrinsification of that common method to support operating on > 64 bits in width and further improve performance. A further issue, yet to be created, will follow up on updating existing JDK code to use the public and/or internal methods where appropriate. Example candidates include String (compareTo, perhaps add a mismatch method and possibly reviewing existing intrinsics, including those for compact Strings), and managed and direct Buffers.
>
> So far i have only documented the new methods operating on byte[], as that will act as the template for the other methods.
>
> Some points:
>
> - Methods operating on Object[] will compare Object elements using Object.equals or associated comparators (as is the case for the existing equals method operating on Object[]).
>
> - Methods operating on float[] or double[] will check such array elements for equality using the IEEE bit layout  (as is the case for the existing equals method operating on float[] or double[]).
>
> - Primitive array element comparison will be performed as if by the boxed primitive type’s compare or compareUnsigned method.
>
> - Range-accepting methods do not support null array values.
>
> - Non-range and range-accepting mismatch methods do not support null array values. (What value should be returned when a mismatch is performed on a null array and an empty array)?
>
> - Speculation: it may be possible that Project Valhalla will enable us to “compress” down methods of certain groups to one “template” method. Even if that is not possible i am not overly concerned about the number of methods added, which represents the maximum set. We could reduce them without a fundamental loss of functionality, but that might have a “semantic” loss requiring developers to roll their own wrappers.

-Chris.

> Thanks,
> Paul.
>
> [1]  https://bugs.openjdk.java.net/browse/JDK-8136924
> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8136924-arrays-mismatch-vectorized-unsafe/webrev/
>
> [2] https://bugs.openjdk.java.net/browse/JDK-8044082
>