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

Paul Sandoz paul.sandoz at oracle.com
Wed Mar 4 15:07:37 UTC 2015

On Mar 4, 2015, at 3:29 PM, Andrew Haley <aph at redhat.com> wrote:

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

Yes, i was unsure how to do that.

I think that setting it in vmversion (in a cpu-dependent way) is a good idea.

Ok.

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.

If so then presumably that would be applicable to both get* and set*?

Could those boolean accepting methods be intrinsified or would they always be Java only?

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, like those used by the mapped byte buffers

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.

Right, this is turning out to be a little more work but overall i think it's worth it.

Paul. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20150304/1c491879/signature.asc>

More information about the hotspot-compiler-dev mailing list