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

Andrew Haley aph at redhat.com
Wed Mar 4 14:29:17 UTC 2015

On 03/04/2015 02:15 PM, Paul Sandoz wrote:

> The flag UseUnalignedAccesses feels a little awkward. IIUC it seems
> to be acting as two things, a flag signalling an unaligned
> architecture and a developer option to disable/enable unaligned
> intrinsics.  Should this flag even be allowed to be set to true on
> aligned architectures?

No.  I guess they should unconditionally set it to false in their
vm_version files.

> Perhaps we need to separate out into two constants? one exposed via
> Unsafe.unalignedAccess, and then a developer flag
> UseUnalignedAccessesIntrinsics (true by default if unaligned
> architecture) to disable intrinsics for testing purposes.

The "constant" exposed via Unsafe.unalignedAccess has to be
initialized to some value.  I think that setting it in vm_version (in
a cpu-dependent way) is a good idea.  For testing purposes it's
important that the whole VM gets a consistent version of whether
unaligned memory accesses are allowed.

> My inclination is to remove the get*Unaligned(..., boolean
> bigEndian) methods and thereby consistently use Bits.swap in the
> heap buffer. A similar pattern applies for float/double conversion.

I suggest that you and John argue that between yourselves!  I think
there's a lot to be said for that approach on architectures which can
do unaligned accesses and have big- and little-endian memory

> It might be useful to have unaligned access methods for the
> single-register addressing mode methods. 

Ah, you mean the methods which simply take an address?  Yes.

> Using those would clean up logic in MappedByteBuffer and perhaps
> similar twiddling methods in Bits could be removed, thus
> consolidating all such logic within Unsafe?

Absolutely, yes.  There are twiddling methods all over the place, and
we should be able to remove most of them.


More information about the hotspot-compiler-dev mailing list