[vector] ByteBuffer byte ordering

[Paul Sandoz]

Thank you for doing that, i forgot to change the implementation after writing the specification.

Looks good, but you missed the Buffer accepting methods that don’t accept an index, follow up later?
(i need to refine the specification to say that the position is adjusted, and then we need to be clear on the mask variants about the result position, it should not be updated for an index if the mask lane is not set…, thereby avoiding out of bounds exceptions).

I still consider it an open question as to whether native order is the correct approach. For now i think what we have is ok, and ensures consistency with intrinsics.

Intuitively it appears ok at least for byte[], as there is a clear mapping to the vector load/stores. But those bytes may have come from somewhere else (e.g. off the network) so we may need to provide an optional argument specifying the byte-order (when order == native-order all is good, and when not some permutation of those bytes is required).

For ByteBuffer we are essentially overriding the order declared by the buffer, which is more questionable.

Paul.


> On Apr 13, 2018, at 11:37 AM, Lupusoru, Razvan A <razvan.a.lupusoru at intel.com> wrote:
> 
> Hi all,
> 
> The Vector API uses ByteBuffers internally in several circumstances including resizing, rebracketing, and also exposes methods from reading from and writing to byte buffers. Ideally, the byte ordering should match the native byte ordering so that there is consistency between intrinsification implementation with vector instructions and java implementation.
> 
> Please take a look at the patch here:
> http://cr.openjdk.java.net/~rlupusoru/panama/webrev_byteorder_00/
> 
> Thanks,
> Razvan