dissecting memory sessions

[Maurizio Cimadamore]

Hi,
After the first preview of the FFM API in Java 19, we have identified a 
couple of areas where the API could use some improvements:

* Clarify the relationship between MemorySegment and MemoryAddress (this 
was addressed in [1]); and
* Polish the MemorySession API, and make segments easier to (safely) 
share with external clients (what this email is about).

While we have explored solutions to better encapsulate memory sessions 
in the past (e.g. by dropping session accessors, as described in [2]), 
nothing seemed to stick. So, for Java 19 we decided to leave session 
accessors on memory segments in place, but give the option to libraries 
to protect against "sneaky" close, by creating non-closeable memory 
session views.

After staring at this problem long enough, it became increasingly clear 
that memory sessions, in their current shape and form, are trying to do 
too much - from allocation, to lifecycle management and more. The issue 
with "sneaky" close is mostly a manifestation of that more fundamental 
problem. In that spirit, we have put together a document which teases 
apart the various "traits" associated with memory sessions, and 
repackages the same traits into an API that provides better 
encapsulation and composition. The document can be found here:

http://cr.openjdk.java.net/~mcimadamore/panama/session_arenas.html

The main move described in the document is to make MemorySession a 
"pure" lifetime abstraction, thus dropping SegmentAllocator and 
AutoCloseable capabilities. Instead, these capabilities are provided by 
a *second* abstraction, called Arena. Crucially, an Arena _has_ a memory 
session, which can e.g. be used to allocate segments that have the same 
lifecycle as that of the arena. This subtle twist, gives us an API that 
is easier to reason about (and to build upon), and one where memory 
segments can be shared freely across clients - premature calls to 
MemorySession::close are no longer possible. At the same time, the API 
now makes a much clearer distinction between sessions that are closeable 
(i.e. sessions created through an Arena) and those that aren't (i.e. 
implicit and global sessions).

Here's a list of the main API changes, and how they will impact clients 
of the FFM API:

* MemorySession no longer has a close() method; try-with-resources 
against MemorySession will now need to use Arena instead;
* Support for non-closeable session views 
(MemorySession::asNonCloseable), and related methods 
(MemorySession::equals/hashCode) has been removed;
* MemorySession::addCloseAction has been removed; instead, clients can 
specify a cleanup action when creating an unsafe segment (i.e. using 
MemorySegment::ofAddress);
* Some of the predicates in MemorySession have been made more robust - 
e.g. instead of MemorySession::ownerThread(), there is now a predicate 
MemorySession::isOwnedBy(Thread).

After careful consideration, we believe that the changes described in 
this document are worth pursuing for the upcoming Java 20 integration 
[3]: they make the API more principled (no more "sneaky" close), while 
retaining a similar expressive power.

Any feedback is greatly appreciated.

Cheers
Maurizio

[1] - https://cr.openjdk.java.net/~mcimadamore/panama/segment_address.html
[2] - 
https://mail.openjdk.org/pipermail/panama-dev/2022-February/016152.html
[3] - 
https://mail.openjdk.org/pipermail/panama-dev/2022-February/016152.html