Places we should use the new ByteBuffer intrinsics

[Paul Sandoz]

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
> 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.