[foreign-memaccess] RFR 8235259: Java layout constants should use native endianness

[Maurizio Cimadamore]

Pushed.

One thing that occurred to me earlier today is that, if we wanted, 
instead of exposing JAVA_INT constants we could instead provide them in 
a more implicit way:

MemoryLayouts::layoutFor(Class<?>)

so:

JAVA_INT == layoutFor(int.class)
JAVA_FLOAT == layoutFor(float.class)

...

The upside of this approach is that it scales beyond primitive - e.g.

layoutFor(int.class) == MemoryLayout.ofSequence(layoutFor(int.class))

[and, when Valhalla is ready, it will even scale to support inline 
classes that are "inline all the way down"]

Another advantage is that we don't have constants whose interpretation 
depends on what ByteOrder::nativeOrder does (which seems problematic 
with respect to make these things foldable at compile-time).

The flip side is that these things are 'less constants' - and probably 
less scrutable by the JIT.


Thoughts?

Maurizio

On 03/12/2019 19:12, Maurizio Cimadamore wrote:
>
> On 03/12/2019 18:49, John Rose wrote:
>> Probably an import static
>> idiom is sufficient
>
> This is where we're currently at.
>
> MemoryLayouts has various constants inside. It has WORA constants 
> (such as BITS_64_BE) as well as internal layouts (such as JAVA_INT - 
> these will be moved, eventually, to the corresponding wrapper classes).
>
> The realization is that if we just provide WORA, it is then very hard 
> to work with Java arrays - which is a very common case for the API 
> (e.g. think about moving data from on-heap to off-heap and back - e.g. 
> to talk to a native library).
>
> It's up to the user to decide which constants he/she wants to use. 
> Each set of constant has a very different audience in mind - and 
> there's no silver bullet.
>
> Maurizio
>