dissecting memory sessions

[Gavin Ray]

Hey Maurizio,
Thanks for such a well-articulated and thought out post.

One question/comment I have (disclaimer: I'm naive about the history of
this area):


>
> *> After staring at this problem long enough, it became increasingly
> clearthat memory sessions, in their current shape and form, are trying to
> dotoo much - from allocation, to lifecycle management and more. *


I recall at one point there being an open PR to add some kind of memory
management/allocator interface (similar to Netty's MemoryManager IIRC)
Pull requests · openjdk/panama-foreign (github.com)
<https://github.com/openjdk/panama-foreign/pull/509>
MemoryManager (Netty API Reference (5.0.0.Alpha4))
<https://netty.io/5.0/api/io.netty5.buffer/io/netty5/buffer/api/MemoryManager.html>

Is this Arena interface filling the same sort of role that the
"MemorySegmentPool + Allocator" PR would have played?
It seemed like a useful PR, but it doesn't look like it had the intent to
be merged, so I was just curious.

Thank you =)

On Wed, Nov 2, 2022 at 1:49 PM Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

> 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/panama-dev/attachments/20221103/0d39bed5/attachment.htm>