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

[Maurizio Cimadamore]

On Fri, 18 Feb 2022 10:36:52 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

>>> 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.

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.

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

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