Lexicographic array comparators

[Andrew Haley]

On 02/10/2015 07:48 PM, Martin Buchholz wrote:

> People will continue to want to access byte arrays (and direct byte
> buffers) with C-like performance, and are currently using Unsafe to
> do so.  Hard to fix for real.  Endianness and unaligned access are
> both non-portable aspects.  People don't want to pay for bounds
> checking and especially not for alignment checking of indexes known
> to be aligned.  Lexicographic comparison is only one use case (that
> happened to be important performance wise for guava).

I've been looking at the code HotSpot generates for
DirectByteBuffer.getXXX() and it's actually pretty good.  In many
cases C2 optimizes away the endianness, alignment, and bounds checks,
and nicely inlines and unrolls everything.  Sure, HotSpot can't always
remove bounds checks, but that's a fairly small price to pay, IMO.

getXXX() methods in HeapByteBuffers, however, aren't intrinsified, so
access to data items larger than bytes is byte-at-a-time and pretty
horrible.  It wouldn't be a huge job to fix this by adding a few
Unsafe.getUnalignedX intrinsics, and then I think we'd have C-like
performance.  Whether it makes sense to do this rather than add a new
API with a bunch of array methods to do the accesses directly is hard
to say.  Doing it in HeapByteBuffer has the advantage of reqiring no
API changes.  We could get it done in the JDK9 timeframe.

Andrew.