Places we should use the new ByteBuffer intrinsics
We discussed where we should be using the new Unsafe unaligned intrinsics. I found these: 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. 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. Andrew.
Re: Places we should use the new ByteBuffer intrinsics
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.
Re: Places we should use the new ByteBuffer intrinsics
Am 16.04.2015 um 15:25 schrieb Paul Sandoz: 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. I guess there are plenty of candidates in coders of sun.nio.cs. Additionally: For some coders it may be reasonable to have get3Bytes() and put3Bytes() methods. At the end it wouldn't make me wonder if we could get rid of the if (src.hasArray())-fork. -Ulf
Re: Places we should use the new ByteBuffer intrinsics
Am 16.04.2015 um 15:25 schrieb Paul Sandoz: 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. I guess there are plenty of candidates in coders of sun.nio.cs. At the end it wouldn't make me wonder if we could get rid of the if (src.hasArray())-fork. -Ulf
