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.
