[SPARK-10134][SQL]Optimization for binary comparison

[chenghao-intel]

In jdk9, probably we can use the JDK API directly for the binary comparison.
https://bugs.openjdk.java.net/browse/JDK-8033148

[cloud-fan]

Do we need to cache the comparator?

[chenghao-intel]

No, not necessary, as lexicographicalComparator() used a static compactor instance internally.

[chenghao-intel]

Actually it's a static final, the function call here should be very easy to be inlined in JIT I think.

[adrian-wang]

use SignedBytes.lexicographicalComparator().compare(x, y) instead.

[SparkQA]

Test build #41312 has finished for PR 8335 at commit f846df5.

• This patch fails Spark unit tests.
• This patch merges cleanly.
• This patch adds no public classes.

[adrian-wang]

I read the code and find the comparator used here is not the same as we previously implemented.
For UnsignedBytes

public static int compare(byte a, byte b) {
  return toInt(a) - toInt(b);
}
public static int toInt(byte value) {
  return value & UNSIGNED_MASK;
}
private static final int UNSIGNED_MASK = 0xFF;

While for java.lang.Byte:

public static int compare(byte x, byte y) {
    return x - y;
}

[adrian-wang]

so let's try

SignedBytes.lexicographicalComparator().compare(x, y)

[chenghao-intel]

Yes, true, I thought all of the binary sorting result will be changed once we update this function, however, seems not. Probably some binary comparison code somewhere else.

[SparkQA]

Test build #41354 has finished for PR 8335 at commit 73b9393.

• This patch passes all tests.
• This patch merges cleanly.
• This patch adds no public classes.

[chenghao-intel]

Closing the Guava(SignedBytes) has exactly the same implementation as current master code.