[foreign] 8220296: Memory access should have layout with explicit endianness

Maurizio Cimadamore maurizio.cimadamore at oracle.com
Thu Mar 7 23:58:06 UTC 2019


I don't get what problem you are trying to address - can you please 
expand further, and maybe provide some examples?

To me, it looks like this is moving us away from the target we have set 
for ourselves.

1) NE = not endianness (that is, endianness is an optional property of 
layouts)

2) accessing memory w/o explicit endiannes is an error (note this is not 
even possible with byte buffer var handle, so there's a clear precedent)

3) only place where NE is tolerated is functions, where in fact 
endianness is redundant

What you do on this patch is bad - because you can write the same code 
(e.g. read memory from NE layout and copy to a LE layout) and it will 
behave differently on different platforms, which is the very thing we 
want to avoid.

Maurizio

On 07/03/2019 19:24, Henry Jen wrote:
> Hi,
>
> After spending quite some time to plug holes everywhere endianness need to be localized(allocation, cast, etc…), I think it’s best to be simple and consistent, and simply enforce LayoutType to have explicit endianness.
>
> This is pretty close to what I came out at very beginning, any NE is really just the host endianness. However, in this edition, the “localize” of endianness happens in LayoutType, not Layout.
>
> With that change, we enforce that function should not have byte-swapped layout.
>
> The webrev[1] is up for review, let me know what you think.
>
> Cheers,
> Henry
>
> [1] http://cr.openjdk.java.net/~henryjen/panama/8220296/0/webrev/


More information about the panama-dev mailing list