Unsafe.{get,put}-X-Unaligned; Efficient array comparison intrinsics

[Andrew Haley]

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
>> Op_ReverseBytesXX 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 Op_ReverseBytesXX 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.