<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">On 09/11/2022 00:20, Uwe Schindler
wrote:<br>
</div>
<blockquote type="cite" cite="mid:dec733f7-6f13-8474-ef8c-a599e35b5f98@apache.org">
<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>
</ul>
</blockquote>
Leaving naming issues for now, I agree that perhaps names landed in
a suboptimal state (esp. MemorySession).<br>
<blockquote type="cite" cite="mid:dec733f7-6f13-8474-ef8c-a599e35b5f98@apache.org">
<ul>
<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>
</blockquote>
<p>The parameter cannot be Arena. You might want to create a mapped
segment that is managed by a global or an implicit session. In
which case you have no arena. Or maybe you have another segment at
hand, and you want to map a segment that has the same lifetime as
the first segment. Again, you don't have an Arena. <br>
</p>
<p>All the API points that accept a "lifetime" need to accept a
MemorySession. An Arena is a client-facing abstraction - it's what
allows you to create a "bounded" lifetime - that is a lifetime
that can start (when the arena is created) and end (when the arena
is closed).</p>
<p>Maurizio<br>
</p>
<blockquote type="cite" cite="mid:dec733f7-6f13-8474-ef8c-a599e35b5f98@apache.org">
<ul>
<li> </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" moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">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 moz-txt-link-freetext" href="mailto:uschindler@apache.org" moz-do-not-send="true">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/" moz-do-not-send="true">https://lucene.apache.org/</a>
<a class="moz-txt-link-freetext" href="https://solr.apache.org/" moz-do-not-send="true">https://solr.apache.org/</a></pre>
</blockquote>
</body>
</html>