Places we should use the new ByteBuffer intrinsics
paul.sandoz at oracle.com
Thu Apr 16 13:25:33 UTC 2015
On Apr 16, 2015, at 12:56 PM, Andrew Haley <aph at redhat.com> wrote:
> We discussed where we should be using the new Unsafe unaligned
> 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
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
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.
More information about the core-libs-dev