[foreign-memaccess] RFR 8228588: MemoryHandles.varHandle still uses implicit platform endiannes

[Maurizio Cimadamore]

On 24/07/2019 19:52, Jorn Vernee wrote:
> Looks good!
>
> For byte carriers (or maybe all carriers) maybe we could provide a 
> VarHandle constant in the MemoryHandle class as well?
>
>     public static final VarHandle BYTE = varHandle(byte.class, 
> ByteOrder.BIG_ENDIAN); // byte order doesn't really matter here

Its not a bad idea - we could provide constants for _all_ carriers in 
both LE/BE.

That said, I'm not 100% sold in the sense that the standard 
MethodHandles class doesn't offer such constants - for instance, take 
MethodHandles::zero - you could have constants for that on each carrier, 
but we don't do that. I don't know whether, in part, there are issues 
with respect to startup cost - e.g. if you put many static constants, 
these will all have to be initialized on first use of the class (and 
these constants are expensive to initialize as they involve some class 
spinning). It would be interesting to know whether my theory is correct, 
or if it's just an API decision of not providing these MH constants.

Maurizio

>
> Jorn
>
> On 2019-07-24 19:18, Maurizio Cimadamore wrote:
>> Hi,
>> in a recent push we removed all implicit endianness from the various
>> factories. Now either you go through a factory and provide explicit
>> endianness or you pick one of the predefined layout constants.
>>
>> I noted that one part of the API (MemoryHandles::varHandle) was still
>> using implicit endianness (and then internally using
>> ByteOrder.nativeOrder()).
>>
>> This patch gets rid of that:
>>
>> http://cr.openjdk.java.net/~mcimadamore/panama/8228588/
>>
>> Now, this makes it a bit more cumbersome when working with 'byte'
>> carriers, where ByteOrder doesn't really apply - but I don't think
>> there's a lot we can do about that.
>>
>> Maurizio