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

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

Yes, i was unsure how to do that.

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

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.

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