memory access - pulling all the threads

[Paul Sandoz]

Nicely done. I think this greatly simplifies the API via composition of two concepts that were hiding behind NativeScope.

Further, it mostly expands the functionality. The ability to lock a ResourceScope and attach close actions to an existing scope are two pieces of functionality that enable an existing resource scope to keep alive segments from another scope e.g. a structure is allocated to manage matrix metadata, accepting a pointer allocated from somewhere else for the matrix elements (the former might have a confined scope, where as the latter might have a shared scope and be retained for much longer).

Paul.

> On Jan 25, 2021, at 9:52 AM, Maurizio Cimadamore <Maurizio.Cimadamore at Oracle.COM> wrote:
...
> This restacking described in this email enhances the Foreign Memory Access API in many different ways, and allows clients to approach the API in increasing degrees of complexity (depending on needs):
> 
> * for smoother transition, coming from the ByteBuffer API, users can only have swap ByteBuffer::allocateDirect with MemorySegment::allocateNative - not much else changes, no need to think about lifecycles (and ResourceScope); GC is still in charge of deallocation
> * users that want tighter control over resources, can dive deeper and learn how segments (and other resources) are attached to a resource scope (which can be closed safely, if needed)
> * for the native interop case, the NativeScope abstraction is retconned to be both a ResourceScope *and* a NativeAllocator - so it can be used whenever an API needs to know how to _allocate_ or which _lifecycle_ should be used for a newly created resource
> * scopes can be locked, which allows clients to write critical sections in which a segment has to be operated upon w/o fear of it being closed
> * the idiom described here can be used to e.g. enhance the ByteBuffer API and to add close capabilities there
> 
> All the above require very little changes to the clients of the memory access API. The biggest change is that a MemorySegment no longer supports the AutoCloseable interface, which is instead moved to ResourceScope. While this can get a little more verbose in case you need a single segment, the code scales _a lot_ better in case you need multiple segments/resources. Existing clients using jextract-generated APIs, on the other hand, are not affected much, since they are mostly dependent on the NativeScope API, which this proposal does not alter (although the role of a NativeScope is now retconned to be allocator + scope).
> 
> You can find a branch which implements some of the changes described above (except the changes to the foreign linker API) here:
> 
> https://github.com/mcimadamore/panama-foreign/tree/resourceScope
> 
> While an initial javadoc of the API described in this email can be found here:
> 
> http://cr.openjdk.java.net/~mcimadamore/panama/resourceScope-javadoc_v2/javadoc/jdk/incubator/foreign/package-summary.html
> 
> 
> Cheers
> Maurizio
> 
> [1] - https://mail.openjdk.java.net/pipermail/panama-dev/2021-January/011700.html
> [2] - https://datasketches.apache.org/docs/Memory/MemoryPackage.html
> [3] - https://mail.openjdk.java.net/pipermail/panama-dev/2021-January/011810.html
> 
>