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