Lexicographic array comparators

[Martin Buchholz]

The addition of array comparison intrinsics makes sense - I've missed them
myself on occasion.

I was surprised that System.arraycopy hasn't been specialized for every
array type.
I guess the JIT is good at specializing all callers.

I don't know whether we will someday regret the explosion of array
comparison methods.
The case for the intrinsic seems more compelling to me.

(Hopefully someone else will do the real review)

On Tue, Feb 10, 2015 at 6:36 AM, Paul Sandoz <paul.sandoz at oracle.com> wrote:

> Hi,
>
> One common use of Unsafe is boost the performance of comparing unsigned
> byte[] by viewing as long[] (for example as performed by Guava or
> Cassandra). To reduce the dependency on Unsafe we need a public and safe
> equivalent that works on all platforms while meeting the performance
> expectations.
>
> In the past we have discussed exposing something on ByteBuffer but i think
> the right thing to explore are comparators for all basic types on
> java.util.Arrays:
>
>  https://bugs.openjdk.java.net/browse/JDK-8033148
>
> This should be explored with the following issue in mind to expose an
> intrinsic that could be leveraged when implemented:
>
>  https://bugs.openjdk.java.net/browse/JDK-8044082
>
> Some preliminary work can be found here:
>
>
> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8033148-Arrays-lexico-compare/webrev/
>
> The "explosion" in methods is annoying. Out of the 8 primitives 4 can be
> signed or unsigned. Objects can be comparable or an explicit comparator can
> be used. There are implicit and explicit ranges. That makes a maximum of 28
> methods, but could be reduced to a minimum of 10, for all basic types.
>
> Comparator instances, for implicit ranges, can easily be created from
> method refs or lambdas.
>
> Thoughts?
>
> Paul.
>