Places we should use the new ByteBuffer intrinsics

Paul Sandoz paul.sandoz at
Thu Apr 16 13:25:33 UTC 2015

On Apr 16, 2015, at 12:56 PM, Andrew Haley <aph at> 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.

>  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 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 mailing list