<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Hey Maurizio,<div>Thanks for such a well-articulated and thought out post.</div><div><br></div><div>One question/comment I have (disclaimer: I'm naive about the history of this area):</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><i>> After staring at this problem long enough, it became increasingly clear<br>that memory sessions, in their current shape and form, are trying to do<br>too much - from allocation, to lifecycle management and more. </i></blockquote><div><br></div><div>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)</div><div><a href="https://github.com/openjdk/panama-foreign/pull/509">Pull requests · openjdk/panama-foreign (github.com)</a><br></div><div><a href="https://netty.io/5.0/api/io.netty5.buffer/io/netty5/buffer/api/MemoryManager.html">MemoryManager (Netty API Reference (5.0.0.Alpha4))</a><br></div><div><br></div><div>Is this Arena interface filling the same sort of role that the "MemorySegmentPool + Allocator" PR would have played?</div><div>It seemed like a useful PR, but it doesn't look like it had the intent to be merged, so I was just curious.</div><div><br></div><div>Thank you =)</div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Nov 2, 2022 at 1:49 PM Maurizio Cimadamore <<a href="mailto:maurizio.cimadamore@oracle.com">maurizio.cimadamore@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
After the first preview of the FFM API in Java 19, we have identified a <br>
couple of areas where the API could use some improvements:<br>
<br>
* Clarify the relationship between MemorySegment and MemoryAddress (this <br>
was addressed in [1]); and<br>
* Polish the MemorySession API, and make segments easier to (safely) <br>
share with external clients (what this email is about).<br>
<br>
While we have explored solutions to better encapsulate memory sessions <br>
in the past (e.g. by dropping session accessors, as described in [2]), <br>
nothing seemed to stick. So, for Java 19 we decided to leave session <br>
accessors on memory segments in place, but give the option to libraries <br>
to protect against "sneaky" close, by creating non-closeable memory <br>
session views.<br>
<br>
After staring at this problem long enough, it became increasingly clear <br>
that memory sessions, in their current shape and form, are trying to do <br>
too much - from allocation, to lifecycle management and more. The issue <br>
with "sneaky" close is mostly a manifestation of that more fundamental <br>
problem. In that spirit, we have put together a document which teases <br>
apart the various "traits" associated with memory sessions, and <br>
repackages the same traits into an API that provides better <br>
encapsulation and composition. The document can be found here:<br>
<br>
<a href="http://cr.openjdk.java.net/~mcimadamore/panama/session_arenas.html" rel="noreferrer" target="_blank">http://cr.openjdk.java.net/~mcimadamore/panama/session_arenas.html</a><br>
<br>
The main move described in the document is to make MemorySession a <br>
"pure" lifetime abstraction, thus dropping SegmentAllocator and <br>
AutoCloseable capabilities. Instead, these capabilities are provided by <br>
a *second* abstraction, called Arena. Crucially, an Arena _has_ a memory <br>
session, which can e.g. be used to allocate segments that have the same <br>
lifecycle as that of the arena. This subtle twist, gives us an API that <br>
is easier to reason about (and to build upon), and one where memory <br>
segments can be shared freely across clients - premature calls to <br>
MemorySession::close are no longer possible. At the same time, the API <br>
now makes a much clearer distinction between sessions that are closeable <br>
(i.e. sessions created through an Arena) and those that aren't (i.e. <br>
implicit and global sessions).<br>
<br>
Here's a list of the main API changes, and how they will impact clients <br>
of the FFM API:<br>
<br>
* MemorySession no longer has a close() method; try-with-resources <br>
against MemorySession will now need to use Arena instead;<br>
* Support for non-closeable session views <br>
(MemorySession::asNonCloseable), and related methods <br>
(MemorySession::equals/hashCode) has been removed;<br>
* MemorySession::addCloseAction has been removed; instead, clients can <br>
specify a cleanup action when creating an unsafe segment (i.e. using <br>
MemorySegment::ofAddress);<br>
* Some of the predicates in MemorySession have been made more robust - <br>
e.g. instead of MemorySession::ownerThread(), there is now a predicate <br>
MemorySession::isOwnedBy(Thread).<br>
<br>
After careful consideration, we believe that the changes described in <br>
this document are worth pursuing for the upcoming Java 20 integration <br>
[3]: they make the API more principled (no more "sneaky" close), while <br>
retaining a similar expressive power.<br>
<br>
Any feedback is greatly appreciated.<br>
<br>
Cheers<br>
Maurizio<br>
<br>
[1] - <a href="https://cr.openjdk.java.net/~mcimadamore/panama/segment_address.html" rel="noreferrer" target="_blank">https://cr.openjdk.java.net/~mcimadamore/panama/segment_address.html</a><br>
[2] - <br>
<a href="https://mail.openjdk.org/pipermail/panama-dev/2022-February/016152.html" rel="noreferrer" target="_blank">https://mail.openjdk.org/pipermail/panama-dev/2022-February/016152.html</a><br>
[3] - <br>
<a href="https://mail.openjdk.org/pipermail/panama-dev/2022-February/016152.html" rel="noreferrer" target="_blank">https://mail.openjdk.org/pipermail/panama-dev/2022-February/016152.html</a><br>
<br>
<br>
</blockquote></div>