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

[Maurizio Cimadamore]

On Wed, 22 Jul 2020 17:04:53 GMT, Henry Jen <henryjen 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.
>
> src/java.base/share/classes/java/lang/invoke/X-VarHandleMemoryAccess.java.template line 107:
> 
>> 106:                 throw MemoryAccessVarHandleBase.newIllegalStateExceptionForMisalignedAccess(address);
>> 107:             }
>> 108:         }
> 
> Seems a little odd to me, as there is no performance gain with skipOffsetCheck.
> 
> The else block check only address but not base and offset separately is not the same, although I think that's correct
> as it's what matters.
> However, if this is desired, I don't see why we don't simply check address without the difference.

The final address is the sum of two components - a base B and an offset O. In a hot loop, B is typically constant (e.g.
the base address of a segment) while O keeps changing. So, if the alignment check is only performed on B, the VM can
prove that this check can be hoisted outside the loop. Of course that leaves the correctness problem - e.g. what if B
is aligned but B + O is not? Luckily, by construction, this is not possible - skipOffsetCheck is only set when we
construct a memory access var handle from a layout - and in that case the layout API make sure that the O part of the
final address is aligned accordingly.

So, while it "looks" as if there's no performance gain, in reality the gain is quite big, because that move allows the
alignment check to be moved outside the loop.

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

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