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@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/w...
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.