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

[Quan Anh Mai]

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

>> This is a possibility which we have explored. In the end we decided against it because we felt splitting session/scope in two would have had a negative effect on API discoverability. Note that non-closeable sessions are not just used for e.g. `MemorySegment::session`, but they are also returned by `MemorySession::global` and `MemorySession::openImplicit`. If we ever do *structured* sessions (e.g. session that give access to any threads that inherit a given Loom scope local), then it is likely that these sessions will be non-closeable too.
>> 
>> Also, you would need to replace most API methods accepting MemorySession with MemorySessionView - and add a subtyping relationhip between MemorySessionView and MemorySession (so that you can pass a MemorySession where a view is expected). Ultimately that all felt a bit too much.
>
>> Ultimately that all felt a bit too much.
> 
> To be clear, it felt too much not because the refactoring was complex (it was not) but because this creates a problem of how do you name the non-closeable entity (`MemorySessionView` is fine when returned by `MemorySegment::session`, less fine when accepted by `MemorySegment::allocateNative`). And if you give it a more general name, then you end up with two abstractions fighting for API visibility.

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.

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

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