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

[Andrew Haley]

On 02/24/2015 11:18 PM, John Rose wrote:
> My bottom line:  I think we should use the internal HotSpot
> API bytes.hpp by surfacing relevant parts of it up into Unsafe.
> (One thing feels wrong about bytes.hpp:  It insists that big-endian
> is the norm for unaligned access.  This is simply a legacy of its
> origin, for classfile and bytecode parsing.)
> 
> Looking at the various platform code for bytes.hpp, I suppose
> one could argue that there are just two cases of interest:
> A single instruction (x86/arm) and a complicated 4-way
> switch (sparc/ppc).  Those could be represented in Java
> code as you suggest, at the cost of some duplication.
> For special platforms which use a third idiom, the intrinsics
> could be adjusted.

OK.

> Distinct big and little endian access modes are also available
> on some machines, such as SPARC (ASI_LITTLE, etc.).
> But I do *not* believe that this capability should be surfaced
> as distinct intrinsics in Unsafe.  Many cpus and source bases
> deal with endian-matching simply by adjoining a separate
> "byte swap" operation to the memory access.  In Java,
> this is already an intrinsic, {Long,Integer,...}.reverseBytes.
> And SPARC already optimizes some compositions of
> byte reversal and memory access to its special ASI_LITTLE
> instructions.
> 
> My second bottom line:  Don't multiply endian options.
> Use reverseBytes calls instead.

OK.

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

OK, I'll look at that.

Andrew.