Array equality, comparison and mismatch

Paul Sandoz paul.sandoz at
Tue Sep 22 16:30:09 UTC 2015


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

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.




More information about the core-libs-dev mailing list