[foreign-memaccess] RFR: 8249879: Split MemorySegment and MemoryAddress [v3]
Jorn Vernee
jvernee at openjdk.java.net
Mon Jul 27 12:27:54 UTC 2020
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
More information about the panama-dev
mailing list