[foreign-memaccess] RFR: 8248487: Add static helpers to access segments [v3]

[Henry Jen]

On Tue, 30 Jun 2020 21:40:36 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This patch addresses some usability issues in the foreign memory API. First, it adds several static accessors for all
>> carrier types in MemoryLayouts (I'm thorn whether to add this in MemoryLayouts or MemoryHandles, suggestions welcome).
>> These accessors provide an access API that is similar to unsafe - all accessors expect a base address plus a byte
>> offset. In most cases the accessors can be used and direct VH usage can be dropped, which might make approaching this
>> API a bit easier.  Secondly, I've added a bunch of helpers to map a segment into _any_ array (as opposed to just
>> `byte[]`). This makes the API more symmetric, given that, after all we _were_ able to create a segment from _any_ array
>> (not just `byte[]`).
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemoryLayouts.java
>   
>   Co-authored-by: Henry Jen <henryjen at ztune.net>

Looks good to me.

Not sure if MemorySegment.toXXXArray() should be moved into MemoryAccess or stay as instance method. Since ofArray
methods are here, it make sense to keep toArray methods here.

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemoryAccess.java line 57:

> 56:     /**
> 57:      * Read a char from given address and offset, with byte order set to {@link ByteOrder#LITTLE_ENDIAN}.
> 58:      * <p>

While the code indicates this is a 16-bit char, I wonder if it's better to clarify the address should have UTF-16 char,
or Java char or wchar_t. Just to make it clear that the address is expected to have UTF-16 encoding?

Same comment applies to al [gs]etChar_[BL]E methods.

-------------

PR: https://git.openjdk.java.net/panama-foreign/pull/221