On Feb 13, 2015, at 2:16 PM, Andrew Haley <a...@redhat.com> wrote: > 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. >
John suggested that a general array mis-match method could be achieved with carefully written Java code [1], and slightly hidden within that is the comment "FIXME: Add Unsafe.getLongMisaligned to avoid this cutout". I am inclined to keep pushing on this array mis-match functionality and it's usages for existing and new stuff in Arrays as well as trying to leverage component pieces in other areas like you suggest. Paul. [1] https://bugs.openjdk.java.net/browse/JDK-8044082?focusedCommentId=13608657&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13608657
