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

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

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.

Andrew.

More information about the hotspot-compiler-dev mailing list