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.

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.



More information about the core-libs-dev mailing list