[foreign-preview] RFR: 8281855: Rename ResourceScope to MemorySession

[Quan Anh Mai]

On Fri, 18 Feb 2022 10:59:59 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> That option was also considered, but discarded because it would make `SegmentAllocator` stateful, e.g. more complex than just a functional interface. Right now it is pretty easy to define a new allocator - but if the allocator has to track lifetime, it becomes harder to define custom ones. Also, saying that, to create an upcall stub you need a `SegmentAllocator`, or that to create an unsafe segment view of a memory address (`MemorySegment::ofAddress`) you need an allocator, is a bit odd - in the sense that you don't really need allocation capabilities there - you just need some kind of lifetime abstraction.
>> 
>> So, I think the "allocation" angle is valid in most cases, but I think that it only works well for native segments and doesn't really generalize to _all_ segments - unsafe views, memory mapped segments, heap segments, etc.
>> 
>> I think separating lifecycle from allocation was a really powerful move, which paid off considerably. Having a single allocator abstraction perform double duty seems a step backwards IMHO.
>> 
>>> I see, rethinking about it, the reason to add a `session` accessor to `MemorySegment` was to properly bind the lifetime of an **allocated** segment to an existing one and to correctly observe that lifetime. It sounds like the functionality of an allocator to me. Maybe we could instead return a `SegmentAllocator` instead (and change `MemorySession` to `SegmentDeallocator` probably) and extend the functionality of a `SegmentAllocator` to check the validity of its associating `MemorySession`. Even if it is not the case we would need to check the state of a `SegmentAllocator` anyway to ensure that we can allocate memory with it. Thanks.
>
>> hat option was also considered, but discarded because it would make `SegmentAllocator` stateful, e.g. more complex than just a functional interface.
> 
> Note that today there is no contract which says that all segments returned by a `SegmentAllocator` must have the same session. While some allocators might behave like that, I think it would not be ok to force that behavior on _all_ allocators. And, we considered to add, perhaps in the future, some small subinterface, like `ScopedSegmentAllocator` which also has a `session` accessor - this would be a good return type for the arena allocator methods, for instance. But this is a move that is orthogonal to the changes described in this PR (and also not a binding one - we can add the sub-interface even at a later point w/o breaking compatibility).

Thanks a lot for your clarification, I still think that having a scope that throw on `close()` sounds a lot like the problem with `UnmodifiableCollection` but it seems the alternatives have been considered already.

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

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