[foreign-memaccess] RFR: 8249879: Split MemorySegment and MemoryAddress [v3]

[Jorn Vernee]

On Fri, 24 Jul 2020 10:54:53 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This patch splits, as the title suggests, the memory segment abstraction from the memory address abstraction, as
>> described in this email:
>> https://mail.openjdk.java.net/pipermail/panama-dev/2020-July/009928.html
>> 
>> Aside from the obvious updates to the two interfaces (and their implementation), this patch greatly simplifies the way
>> memory access var handles are generated; instead of spinning them on the fly (see `MemoryAccessVarHandleGenerator`,
>> which is now removed) now all var handles can be derived from a primitive from which takes a segment and a byte offset.
>> This caused the removal of several methods in the `JavaLangInvokeAccess` interface.  The new memory segment interface
>> has some more methods to perform slicing - which can basically be used to give a new base to an existing segment and
>> can therefore be used in a lot of cases as a replacement for `MemoryAddress::addOffset`.  The memory address interface
>> is simplified, and features an additional `segmentOffset` method, which returns the byte offset of an address relative
>> to the given segment (this is similar to the old `MemorySegment::rebase` method, which is now removed).  The
>> `MemoryAccess` class needed a lot of tweaks in the various signatures, to take a segment instead of a base address.  I
>> tried to update the documentation as best as I could, but it's possible I missed some references to the old
>> relationship between segment and addresses, please double check.  Of course integrating this patch is gonna cause
>> issues in foreign-abi and foreign-jextract, as these branches make (heavy) use of memory access var handles. I suspect
>> that integration will trigger a merge failure, so we can fix followup issues as part of the merge process, so that we
>> can guarantee that all the branches remain buildable.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address Paul's review comments.

Marked as reviewed by jvernee (Committer).

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

> 56:         MemoryLayout.ofValueBits(32, ByteOrder.BIG_ENDIAN).withName("value")
> 57: ));
> 58:  * }</pre></blockquote>

There's one too many closing parenthesis here, and the sentence above still talks about a SequenceLayout, which is now
removed.

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemorySegment.java line 300:

> 299:      */
> 300:     default MemorySegment asSlice(MemoryAddress address) {
> 301:         return asSlice(address.segmentOffset(this));

FWIW the `MemorySegment asSlice(MemoryAddress address, long newSize)` overload is still missing from the matrix.

src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/MemoryAddressImpl.java line 50:

> 49:     @Override
> 50:     public long segmentOffset(MemorySegment segment) {
> 51:         Objects.requireNonNull(segment);

Maybe this makes more sense on MemorySegment as `offsetOf(MemoryAddress)` ? WDYT?

test/micro/org/openjdk/bench/jdk/incubator/foreign/LoopOverNonConstantMapped.java line 149:

> 148:         for (int i = 0; i < ELEM_SIZE; i ++) {
> 149:             res += MemoryAccess.getIntAtIndex(segment, i * CARRIER_SIZE);
> 150:         }

Why this multiply by CARRIER_SIZE? That should be done by the accessor.

test/jdk/java/foreign/TestVarHandleCombinators.java line 114:

> 113:                 for (long j = 0; j < inner_size; j++) {
> 114:                     vh.set(segment, i * 40 + j * 8, count);
> 115:                     assertEquals(

Can this be done with combinators instead of manual offsets like before? Mostly curious about how this use-case changes.

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

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