Array equality, comparison and mismatch

[Tagir F. Valeev]

Hello!

Quite interesting feature. Isn't it a typo here?
http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8136924-arrays-mismatch-vectorized-unsafe/webrev/src/java.base/share/classes/java/util/ArraysSupport.java.html

419    if (!Float.isNaN(a[aFromIndex + i]) || !Float.isNaN(b[aFromIndex + i]))
487    if (!Double.isNaN(a[aFromIndex + i]) || !Double.isNaN(b[aFromIndex + i]))

Seems that it should be b[bFromIndex + i], not b[aFromIndex + i] in
both cases.

As for methods like compare(byte[] a, int aFromIndex, int aToIndex,
                            byte[] b, int bFromIndex, int bToIndex)

Is it better to introduce two to-indices instead of single length
argument (like in System.arraycopy)? Six method arguments looks
a little bit crowded.

As for method count, it would be really nice and user-friendly were it
be possible to add methods to the array types themselves, so users can
write:

byte[] b1;
byte[] b2;

int mismatchPos = b1.mismatch(b2);
Comparator<byte[]> cmp = byte[]::compareTo;

This somehow works with clone() method (I guess, there is some very
special code in javac for this). There could be some special abstract
classes like java.lang.ByteArray with private constructor (using
this[idx] to access elements) and all byte[] arrays could extend them,
so JDK developers could add new methods to arrays without modifying
the compiler. Well, that's just my fantasies about the better
world...

With best regards,
Tagir Valeev.

PS> Hi,

PS> Please review the following which adds methods to Arrays for
PS> performing equality, comparison and mismatch:

PS>   https://bugs.openjdk.java.net/browse/JDK-8033148
PS>  
PS> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8033148-Arrays-lexico-compare/webrev/
PS>  
PS> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8033148-Arrays-lexico-compare/specdiff/overview-summary.html

PS> The motivation behind this is the use of Unsafe in popular
PS> libraries and frameworks to speed up the lexicographical comparison of byte arrays.

PS> This issue focuses on the API and functional implementations. A
PS> follow up issue [1] tracks updating the implementations to use a
PS> common method that leverages Unsafe to improve performance. A
PS> further issue [2] tracks the intrinsification of that common
PS> method to support operating on > 64 bits in width and further
PS> improve performance. A further issue, yet to be created, will
PS> follow up on updating existing JDK code to use the public and/or
PS> internal methods where appropriate. Example candidates include
PS> String (compareTo, perhaps add a mismatch method and possibly
PS> reviewing existing intrinsics, including those for compact
PS> Strings), and managed and direct Buffers.

PS> So far i have only documented the new methods operating on
PS> byte[], as that will act as the template for the other methods.

PS> Some points:

PS> - Methods operating on Object[] will compare Object elements
PS> using Object.equals or associated comparators (as is the case for
PS> the existing equals method operating on Object[]).

PS> - Methods operating on float[] or double[] will check such array
PS> elements for equality using the IEEE bit layout  (as is the case
PS> for the existing equals method operating on float[] or double[]).

PS> - Primitive array element comparison will be performed as if by
PS> the boxed primitive type’s compare or compareUnsigned method.

PS> - Range-accepting methods do not support null array values.

PS> - Non-range and range-accepting mismatch methods do not support
PS> null array values. (What value should be returned when a mismatch
PS> is performed on a null array and an empty array)?

PS> - Speculation: it may be possible that Project Valhalla will
PS> enable us to “compress” down methods of certain groups to one
PS> “template” method. Even if that is not possible i am not overly
PS> concerned about the number of methods added, which represents the
PS> maximum set. We could reduce them without a fundamental loss of
PS> functionality, but that might have a “semantic” loss requiring
PS> developers to roll their own wrappers.

PS> Thanks,
PS> Paul.

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

PS> [2] https://bugs.openjdk.java.net/browse/JDK-8044082