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.