[foreign-memaccess+abi] RFR: 8301360: Add dereference layout paths to memory layout API

[Jorn Vernee]

On Mon, 30 Jan 2023 21:38:03 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/foreign/MemoryLayout.java line 658:
>> 
>>> 656:          * @return a path element which dereferences an address layout.
>>> 657:          */
>>> 658:         static PathElement dereferenceElement(MemoryLayout layout) {
>> 
>> This method needs to be restricted, I believe. Since it allows resizing a MemorySegment. The other overload of `dereferenceElement` is already covered because attaching a pointee layout to an address layout is restricted already.
>> 
>> Consider the following:
>> 
>> 
>> StructLayout hasAddr = MemoryLayout.structLayout(ADDRESS.withName("addr"));
>> 
>> MemorySegment rawSeg = MemorySegment.allocateNative(0, SegmentScope.auto()); // inaccessible segment
>> // rawSeg.get(JAVA_INT, 0); // not allowed
>> MemorySegment addrHolder = MemorySegment.allocateNative(hasAddr, SegmentScope.auto());
>> addrHolder.set(ADDRESS, 0, rawSeg); // fine
>> VarHandle derefHandle = hasAddr.varHandle(groupElement("addr"), dereferenceElement(JAVA_INT));
>> int x = derefHandle.get(addrHolder); // oops!
>> 
>> 
>> Assuming I eye-balled this code correctly, I think this is problematic?
>
> Sure - the layout accepting one needs to be restricted - I started off with only the other one (which doesn't need to be restricted), then added the layout accepting one, and forgot to add the restricted check. Any way - as a validation, do we agree that it is handy to have both forms? If you have a layout like A -> B -> A, there is no way to attach target layouts statically - which is the main reason why I added that variant.

Yes, it seems good to have it for that case.

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

PR: https://git.openjdk.org/panama-foreign/pull/776