ByteBuffer views, alignment, word tearing

[Paul Sandoz]

Hi Andrew,

See also:

https://bugs.openjdk.java.net/browse/JDK-8151163 <https://bugs.openjdk.java.net/browse/JDK-8151163>

http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8151163-buffer-unsafe-unaligned-access/ <http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8151163-buffer-unsafe-unaligned-access/>

http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8151163-buffer-unsafe-unaligned-access/webrev/ <http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8151163-buffer-unsafe-unaligned-access/webrev/>

http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8151163-buffer-unsafe-unaligned-access-hotspot/webrev/ <http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8151163-buffer-unsafe-unaligned-access-hotspot/webrev/>

I opted to directly use Unsafe rather than defer. I am not sure it’s always possible to defer to the underlying buffer since its positional and order state is mutable.

I got bogged down investigating some regressions on SPARC for long values that are misaligned such that 8 bytes are read. But i planned to proceed with this and see if we can clean up SPARC later on, but then i forgot until you reminded me :-)

Paul.


> On 11 Jul 2016, at 17:08, Andrew Haley <aph at redhat.com> wrote:
> 
> I saw a few ACCEPTABLE_SPEC results for ByteBuffer views in jcstress.
> This results from word tearing.  I was rather surprised, because I'd
> worked on the HeapByteBuffer implementation, and I knew that on we
> would't expect to see any word tearing for HeapByteBuffers or
> DirectByteBuffers, at least for aligned word fetches and stores.
> 
> Unfortunately, we're still doing this in e.g. ByteBufferAsIntBufferL:
> 
>    public int get(int i) {
>        return Bits.getIntL(bb, ix(checkIndex(i)));
>    }
> 
> where Bits.getIntL is defined as:
> 
>   static int getIntL(ByteBuffer bb, int bi) {
>        return makeInt(bb._get(bi + 3),
>                       bb._get(bi + 2),
>                       bb._get(bi + 1),
>                       bb._get(bi    ));
>    }
> 
> instead of what I'd thought we were doing, which was:
> 
>    public int get(int i) {
>        return bb.getInt(ix(i));
>    }
> 
> ... so we get slow byte-at-a-time implementations of all the getX and
> putX methods -- with no HotSpot intrinsic optimizations.  And we get
> word tearing even though the data in a ByteBuffer view is always
> aligned.
> 
> It never occurred to me that the ByteBuffer views didn't defer to the
> ByteBuffer.{get,put} methods.  Either that or I forgot, but I should
> have fixed ByteBuffer views at the same time as HeapByteBuffer.
> 
> It's not a huge job to fix this, but rather late for JDK 9.
> 
> Andrew.
> 
> 
> [P.S.  It's a little bit more complicated than this because a
> ByteBuffer view has the endianness that its parent had when the view
> was created.  But that's not hard to do.]