[foreign-memaccess+abi] RFR: 8263018: Improve API for lifecycle of native resources [v10]

[Maurizio Cimadamore]

On Mon, 15 Mar 2021 22:05:30 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>>> Less sure about `SegmentAllocator.of(scope)` -> `ResourceScope.toAllocator()`, FWIW I noticed this is a subset of `malloc`:
>>> 
>>> ResourceScope scope = ...
>>> SegmentAllocator fixedScopeAllocator = SegmentAllocator.malloc(() -> scope);
>>> 
>>> There might also be some interconnections with `ScopedSegmentAllocator`? Seems like we either want to compose through inheritance or have some bi-direction between the two abstractions.
>> 
>> Good point - if we had a ScopedSegmentAllocator abstraction, I believe creating an allocator from a scope would not be as important (if clients need both an allocator and a scope, well they can just allocate a ScopedSegmentAllocator).
>
>> > Less sure about `SegmentAllocator.of(scope)` -> `ResourceScope.toAllocator()`, FWIW I noticed this is a subset of `malloc`:
>> > ResourceScope scope = ...
>> > SegmentAllocator fixedScopeAllocator = SegmentAllocator.malloc(() -> scope);
>> > There might also be some interconnections with `ScopedSegmentAllocator`? Seems like we either want to compose through inheritance or have some bi-direction between the two abstractions.
>> 
>> Good point - if we had a ScopedSegmentAllocator abstraction, I believe creating an allocator from a scope would not be as important (if clients need both an allocator and a scope, well they can just allocate a ScopedSegmentAllocator).
> 
> I made an attempt at this - captured in the following javadoc:
> 
> http://cr.openjdk.java.net/~mcimadamore/panama/resourceScope-javadoc_v6_exp/
> 
> There is a new ScopedMemoryAllocator - and some of the existing factory now return that. Note that now the difference between SegmentAllocator.malloc and SegmentAllocator.scoped is cleared, as only the latter gives you a ScopedSegmentAllocator.
> 
> All the arena allocators are also ScopedSegmentAllocators.
> 
> The recycling allocator has been moved off to the side in MemorySegment::toAllocator.
> 
> Is this an improvement? While more verbose than the old native scope, I think there's a lot more composition going on here, as now users can select full spectrum of { shared, confined } x { bounded vs. unbounded allocation } x { explicit vs. implicit close } - the former NativeScope used to be a point (although common) in this space: confined x { bounded vs. unbounded allocation } x explicit close.

Small observation: I realized that _all_ segment allocators can be associated with a scope. For allocators in which the scope is not important, we can just return the global scope.

In other words, associating a scope to an allocator is mostly harmless - either the allocator does have a lifecycle (and that is managed by the scope), or the allocator does not have one (in which case a neutral scope like global scope can be used).

This might address the problem of having a single entity which is connected to both an allocator and a scope - but it doesn't solve the usability problem of the try-with-resources. Unless we make SegmentAlocator AutoCloseable. But, if we make SegmentAllocator auto-closeable on the basis that an allocator has-a scope - then, on that basis it seems that even MemorySegment, VaList, ... should join for the ride? This seems like a slippery slope.

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

PR: https://git.openjdk.java.net/panama-foreign/pull/466