[foreign-memaccess+abi] RFR: 8291473: Unify MemorySegment and MemoryAddress [v3]

[Maurizio Cimadamore]

On Thu, 28 Jul 2022 13:54:03 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update src/java.base/share/classes/jdk/internal/foreign/abi/UpcallStubs.java
>>   
>>   Co-authored-by: Jorn Vernee <JornVernee at users.noreply.github.com>
>
> src/java.base/share/classes/jdk/internal/foreign/abi/BindingSpecializer.java line 448:
> 
>> 446:     private static boolean shouldAcquire(Class<?> type) {
>> 447:         // by this time, the only MemorySegment left are those for by-ref args
>> 448:         return type == MemorySegment.class;
> 
> I don't quite get the comment here. Looking at the caller of `shouldAcquire`, it seems like we can also call this for by-value struct parameters. This seems different from what we do today in that we would also end up acquiring scopes of by-value structs, which is not needed.

I see - I might have been confused into thinking that by-value args were already lowered, which is clearly not the case. We need to piggy back on the function descriptor.

> src/java.base/share/classes/jdk/internal/foreign/abi/SharedUtils.java line 203:
> 
>> 201: 
>> 202:     private static MemorySegment bufferCopy(MemorySegment dest, MemorySegment buffer) {
>> 203:         NativeMemorySegmentImpl.makeNativeSegmentUnchecked(dest.address(), buffer.byteSize()).copyFrom(buffer);
> 
> The fact that we need to create an unchecked segment from `dest` here seems like a bit of a smell. Although I acknowledge that it recreates the old behavior.
> 
> The target here should be the artificial leading address added by CallArranger, which should already be using the unbounded address layout when boxing the address. What happens if you just use `dest.copyFrom(buffer)`?

I'll try

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

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