<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi,</p>
<p>sorry for the late reply (I was privately discussing with
Maurizio already). From the Lucene standpoint only using
MemorySegment on top of mmapped files, I see no problems, we just
need to replace MemorySession by Arena in our code (I plan to
change our code to use just pass Autocloseable around to allow us
to unmap shared mmaped files).</p>
<p>But when looking at the API I found some minor problems:</p>
<ul>
<li>Naming: "MemorySession", "MemorySegment".... but now "Arena".
I'd rename it to "MemoryArena" to make it consistent. Personally
I have my problems with the term "Arena", to me it makes it hard
to understand.</li>
<li>In Lucene we work with MMap mainly - I did not look into other
parts on Panama, but for memory mapping I was wondering about
the signature of FileChannel#map(..., MemorySession). The last
parameter is currently a MemorySession and was not changed to
Arena. IMHO, this should be Arena, because to me it looks like
an *allocation* of a mapped file slice and goes in line with
other allocatior methods. You use an Arena as factory for
MemorySegments. FYI, in our current code in Lucene when we pass
Arena around, we need to get the Session from it first. For
newcomers this is hard to understand, because the MemorySession
has lost importance and is no longer a first class citizen to
get. Its hard to figure out how to get the session. Also the
code that maps the file should be under control to unmap it and
for that the arena is important. With the session alone you
cannot unmap it. So to me mmap a segment and releasing it should
use same class (Arena). <br>
</li>
</ul>
<p>Uwe<br>
</p>
<div class="moz-cite-prefix">Am 02.11.2022 um 18:48 schrieb Maurizio
Cimadamore:<br>
</div>
<blockquote type="cite"
cite="mid:2e640202-375d-11d4-3f6c-0669dfb0454e@oracle.com">Hi,
<br>
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:
<br>
<br>
* Clarify the relationship between MemorySegment and MemoryAddress
(this was addressed in [1]); and
<br>
* Polish the MemorySession API, and make segments easier to
(safely) share with external clients (what this email is about).
<br>
<br>
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.
<br>
<br>
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:
<br>
<br>
<a class="moz-txt-link-freetext" href="http://cr.openjdk.java.net/~mcimadamore/panama/session_arenas.html">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
"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).
<br>
<br>
Here's a list of the main API changes, and how they will impact
clients of the FFM API:
<br>
<br>
* MemorySession no longer has a close() method; try-with-resources
against MemorySession will now need to use Arena instead;
<br>
* Support for non-closeable session views
(MemorySession::asNonCloseable), and related methods
(MemorySession::equals/hashCode) has been removed;
<br>
* MemorySession::addCloseAction has been removed; instead, clients
can specify a cleanup action when creating an unsafe segment (i.e.
using MemorySegment::ofAddress);
<br>
* 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).
<br>
<br>
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.
<br>
<br>
Any feedback is greatly appreciated.
<br>
<br>
Cheers
<br>
Maurizio
<br>
<br>
[1] -
<a class="moz-txt-link-freetext" href="https://cr.openjdk.java.net/~mcimadamore/panama/segment_address.html">https://cr.openjdk.java.net/~mcimadamore/panama/segment_address.html</a>
<br>
[2] -
<a class="moz-txt-link-freetext" href="https://mail.openjdk.org/pipermail/panama-dev/2022-February/016152.html">https://mail.openjdk.org/pipermail/panama-dev/2022-February/016152.html</a>
<br>
[3] -
<a class="moz-txt-link-freetext" href="https://mail.openjdk.org/pipermail/panama-dev/2022-February/016152.html">https://mail.openjdk.org/pipermail/panama-dev/2022-February/016152.html</a>
<br>
<br>
<br>
</blockquote>
<pre class="moz-signature" cols="72">--
Uwe Schindler
<a class="moz-txt-link-abbreviated" href="mailto:uschindler@apache.org">uschindler@apache.org</a>
ASF Member, Member of PMC and Committer of Apache Lucene and Apache Solr
Bremen, Germany
<a class="moz-txt-link-freetext" href="https://lucene.apache.org/">https://lucene.apache.org/</a>
<a class="moz-txt-link-freetext" href="https://solr.apache.org/">https://solr.apache.org/</a></pre>
</body>
</html>