Unsafe.{get,put}-X-Unaligned; Efficient array comparison intrinsics (original) (raw)

Andrew Haley aph at redhat.com
Wed Mar 4 09:25:01 UTC 2015

On 03/03/15 20:48, John Rose wrote:

On Mar 2, 2015, at 11:30 AM, Andrew Haley <aph at redhat.com> wrote:

On 02/25/2015 04:43 PM, Andrew Haley wrote: I have done this as much as is possible, but methods which assemble and split sub-words are necessarily endian-dependent. I have separated the native big- and little-endian code into two classes, only one of which will ever be loaded into a system. Here is a way to merge the twin classes, using gated "pick" operators: http://cr.openjdk.java.net/~jrose/draft/Unsafe.NativeEitherEndian.java If merging them actually works, then the merged result should be folded back into Unsafe, and static variables used everywhere. I think this is better than quasi-duplicate code, if it optimizes right.

That looks very nice. I'll see if it optimizes well.

Suggestion: Have getIntUnaligned take an optional boolean parameter, which is "bigEndian" (since that's relatively exceptional). An extra line of code can conditionally swap the bytes, taking both the flag and the platform into account. Default value of the boolean is whatever is natural to the platform. If you specifically want Java's big-endian order, you specify true, etc. I've done this in Java. I tried some HotSpot intrinsic code to handle the "bigEndian" parameter but foundered when I noticed that OpReverseBytesXX nodes are optional, so an intrinsic might either be emitted as an instruction or a call to a native method. This was all too messy so I reverted to doing it in Java; the code quality does not seem to suffer as a result of this. (Another possibility is to define intrinsics which would only be used if OpReverseBytesXX nodes were supported, but I don't know that such an intrinsic would buy us anything.) I'm surprised it backed off to a native method. It should have backed off to bytecode equivalent to what you wrote (see Integer.java for the code).

I'm sorry, I misspoke. I mean that reverse may be emitted as a call to a method if the C2 node isn't supported.

There are several places in the JDK where we have special cases for alignment, endianness, and arrays and some could benefit from use of these new methods, but except for HeapByteBuffers I haven't changed anything. It would be good to call them out; we can file followup bugs.

Okay.

I am aware that the code is uncommented. I will fix that once we agree about what to do next.

http://cr.openjdk.java.net/~aph/unaligned.hotspot.1/ http://cr.openjdk.java.net/~aph/unaligned.jdk.2/ I like it! I'm a little puzzled by the meaning of UseUnalignedAccesses. From a portable point of view, it sounds like the JVM will be using special access operators. But in fact, it is using the normal aligned memory access operators for unaligned accesses also. (Remember, from a portability point of view the normal memory access operators work only on aligned addresses.) I don't have a nice replacement name thought.

Sure. It's a developer-only flag, and we have something of a tradition of obscurely-named developer flags. But I might be able to think of a better name.

Andrew.

More information about the hotspot-compiler-dev mailing list