[vector] ByteBuffer byte ordering

[Paul Sandoz]

> On Apr 13, 2018, at 2:29 PM, John Rose <john.r.rose at oracle.com> wrote:
> 
> On Apr 13, 2018, at 2:09 PM, Lupusoru, Razvan A <razvan.a.lupusoru at intel.com <mailto:razvan.a.lupusoru at intel.com>> wrote:
>> 
>> I agree - the correct code actually should have preserved byte order for all API methods that actually take in ByteBuffer argument.
>> Here is updated patch:http://cr.openjdk.java.net/~rlupusoru/panama/byteorder_01/byteorder_01.patch <http://cr.openjdk.java.net/~rlupusoru/panama/byteorder_01/byteorder_01.patch>
>>  
>> Namely, the fixed version does the following things:
>> -          For byte arrays, since internally it uses byte buffer, it uses native ordering
>> -          For methods accepting ByteBuffer, they need to maintain ordering.
>> o   For case where ByteBuffer is duplicated (namely the version taking ByteBuffer + index), the order must be overridden since duplication of ByteBuffer does not preserve original ordering but updates it to be BIG_ENDIAN.
>>  
>> Let me know what you think now! Thanks for catching this error.
> 
> I think you caught that!  And I agree it's a good one.  I was more
> concerned with the byte order on the internally created ones, but
> of course (on second thought) we can specify what we want for
> those.  Although it would be in some way cleaner to allow the
> user to control byte ordering for rebracketing.  (Is that your
> concern, Paul?)

I was concerned about the default and lack of control of order when loading/storing from/to byte[], which as you say is a design smell.


>  Maybe the right answer is to allow an optional
> argument (at some point) to rebracketing which specifies
> input and/or output byte orders.  


I would prefer if we did not get into ordering for the reshape/rebracket. 

These reshape/rebracketing (and resize) are intended to preserve the bits of the vector (with the exception of truncation when the shape size is reduced). I find these methods tricky to reason about as is :-)

If byte reordering is required other operations can be used e.g. like using a swizzle on the bytes of a byte vector then rebracketing to an int vector. If needed we could provided some pre-cooked Shuffles for flipping order.

Paul.


> Relying on native byte order
> implicitly is a design smell in Java APIs.
> 
> In your new javadoc you seem to have dropped " / Byte.SIZE"
> after "v.bitSize()" even though it will be significant in the new text.
> 
> — John