On Apr 16, 2015, at 12:56 PM, Andrew Haley <a...@redhat.com> wrote: > We discussed where we should be using the new Unsafe unaligned > intrinsics. > > I found these: >
They look like good candidates. I did a quick search in the JDK src code (usages of getByte/Short/Int/Long) and could not find any others. > ByteBufferAs$Type$Buffer. These use slow bytewise accesses, > and should be converted. > > DirectByteBuffer. This probes for unaligned memory support > and uses byte-by-byte accesses if it isn't available. We > should probably convert it after doing some performance > measurements. > That should be a nice cleanup, i would be surprised if it resulted in any performance issues but it would be good to check as you say. > sun.security.provider.ByteArrayAccess. This uses a lot of > hand-carved custom code to handle data which largely > duplicates that now in Unsafe, but big-endian platforms (and > little-endian ones which don't support unaligned accesses) > always use byte-by-byte accesses for unaligned data. Again, > we should probably convert it after doing some performance > measurements. > There is also an assumption in the following comment in sun.security.provider.ByteArrayAccess.b2lBig that i presume is no longer relevant: // In the current HotSpot memory layout, the first element of a // byte[] is only 32-bit aligned, not 64-bit. // That means we could use getLong() only for offset 4, 12, etc., // which would rarely occur in practice. Instead, we use an // optimization that uses getInt() so that it works for offset 0. Paul.
