[foreign-memaccess+abi] RFR: 8310362: Improve composability of handle derived from layouts

[Jorn Vernee]

On Wed, 21 Jun 2023 12:17:14 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Me and Maurizio have been discussing how to better address certain use cases like accessing structs with variable length array members, or matrices that have a dynamic row and column size.
>> 
>> The solution we came up with is captured in this patch. It adds an additional base offset parameter to the handles produced by `MemoryLayout::varHandle`, `MemoryLayout::sliceHandle` and `MemoryLayout::byteOffsetHandle`. This allows these handles to be composed with other offset computations that are not necessarily derived from layouts.
>> 
>> This patch also adds a `scale` method to MemoryLayout, which can be used to scale and index by the size of a layout. Essentially: `offset + layout.byteSize() * index`. This is useful for expressing ad-hoc offset computations. A `scaleHandle` method is also added for convience, which returns a MethodHandle for `scale` bound to the receiver layout.
>> 
>> Both these changes allowed for several simplifications:
>> - `MethodHandles::memorySegmentViewVarHandle` can be removed, as it's now exactly the same as calling ML::varHandle on a ValueLayout with an empty layout path. (the former method also didn't take advantage of the access handle cache found on ValueLayouts).
>> - `ValueLayout::arrayHandle` is removed, as most use cases can now simply be expressed using ML::varHandle + ML::scaleHandle. e.g.:
>> 
>> MethodHandles.collectCoordinates(layout.varHandle(),
>>             1, MethodHandles.insertArguments(layout.scaleHandle(), 0, 0L));
>
> src/java.base/share/classes/java/lang/foreign/MemoryLayout.java line 456:
> 
>> 454:      * {@code 0 <= x_i < b_i}, where {@code 1 <= i <= n}, or {@link IndexOutOfBoundsException} is thrown.
>> 455:      * <p>
>> 456:      * Multiple path sections can be chained, with <a href=#deref-path-elements>dereference path elements</a>.
> 
> I'm not too fond of the "path section" concept. Perhaps we could just talk about paths and sub-paths? Not 100% sure. A possible angle would be to show that a path containing dereference elements is broken up into distinct paths, which are then joined together using combinators.

The previous doc talks about deref paths at the end, but then shows an alternative way to compute the accessed address. I thought this looked conflicting, so I changed this part to talk about the simple case first.

We could pull up the full blown address computation as well

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

PR Review Comment: https://git.openjdk.org/panama-foreign/pull/840#discussion_r1238780952