[foreign] "implicit" conversions in the memory access API

[Paul Sandoz]

I agree that the current state of affairs is defensible with regards to creating an allocator from various inputs.

You are right about the "general sense of unease”. That’s what stood out to me in the original email. I believe with JNI and direct byte buffers this is not possible because the DBB is passed as a ref to the JNI native method, and is this kept live for the duration of the call.

Paul.

> On Mar 25, 2021, at 2:56 PM, Maurizio Cimadamore <Maurizio.Cimadamore at Oracle.COM> wrote:
> 
> 
> 
> On 25/03/2021 21:28, Maurizio Cimadamore wrote:
>>> * we do nothing and leave the API as is (1=D, 2=B) 
>>> * we go back, remove the Addressable interface (1=A, 2=B) 
>>> * as before, but we also remove the ResourceScope overloads - no magic conversions, everything is always explcit (1=A, 2=A) 
>>> * we see if there's an interface name we like for ResourceScope -> SegmentAllocator, and remove the overloads, which would then be no longer necessary (1=D, 2=D) 
>>> * make ResourceScope <: SegmentAllocator, but leave Addresable (1=D, 2=C)
>> I think it's either the first bullet (leave everything as is), or the 4th bullet (find a common supertype). 
> One advantage of a common supertype is that MemorySegment could join in too.
> 
> Let's imagine we have an interface Fooable:
> 
> ResourceScope <: Fooable
> SegmentAllocator <: Fooable
> MemorySegment <: Fooable
> 
> then, if you have a memory segment-producing API method, you can write it as:
> 
> MemorySegment convertString(String s, Fooable f) { ... }
> 
> then you can use this as:
> 
> convertString("hello", scope) --> allocate a new segment associated with 'scope' and store the results in there
> convertString("hello", allocator) --> allocate a new segment, using allocator, and store the results in there
> convertString("hello", segment) --> store the results in the provided segment
> 
> Another possibility which we considered at some point, instead of adding a common supertype, just add some conversion method (a la MemorySegment.address()):
> 
> MemorySegment convertString(String s, SegmentAllocator) { ... }
> 
> then you can use this as:
> 
> convertString("hello", scope.toAllocator()) --> allocate a new segment associated with 'scope' and store the results in there
> convertString("hello", allocator) --> allocate a new segment, using allocator, and store the results in there
> convertString("hello", segment.toAllocator()) --> store the results in the provided segment
> 
> Which is not as concise as the former, but plays better with MethodHandle.invokeExact.
> 
> That said, with some sprinkling of static imports, with current code you can do (assuming there are no overloads):
> 
> convertString("hello", scoped(scope)) --> allocate a new segment associated with 'scope' and store the results in there
> convertString("hello", allocator) --> allocate a new segment, using allocator, and store the results in there
> convertString("hello", prefix(segment)) --> store the results in the provided segment
> 
> Which is not that worse (well, at least it seems bikeshed material as to whether this is worse or better than the former).
> 
> So, I think overall, I stand by the current design - it seems the less evil of the various alternatives. The provided overloads reduce verbosity in the common case, but even if there were no overloads (e.g. in user code) the fallback is not so terrible, thanks to the static factories to create allocators from segments and scopes.
> 
> That said, I think we uncovered some general sense of unease with how the API is promoting use of implicit segments even with the Linker, and how this can lead to trouble (when segments are converted to addresses). I think we should focus our energy to try and see if we can make the linker world more friendly to that use case, and if not, cut back on implicit segments (in the CLinker API).
> 
> Maurizio
> 
> 
>