<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">On 03/11/2022 14:07, Radosław Smogura
wrote:<br>
</div>
<blockquote type="cite" cite="mid:DB7PR07MB5499C8EA98AD38020AE19E9CE0389@DB7PR07MB5499.eurprd07.prod.outlook.com">
<meta name="Generator" content="Microsoft Word 15 (filtered
medium)">
<style>@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}.MsoChpDefault
{mso-style-type:export-only;}div.WordSection1
{page:WordSection1;}</style>
<div class="WordSection1">
<p class="MsoNormal">Hi Maurizo,</p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Thank you for sharing this approach. I
would have question related to closing arenas, and I was
thinking about creating pooling arena which will return
allocated segments back to the pool like in case of pooling
allocator.</p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Firstly, minor thing, Arena class is sealed
so I can’t create wrapper around it?</p>
</div>
</blockquote>
I don't think Arena needs to be sealed, as there's nothing too magic
about it. Opening it up allows clients to decorate arenas easily.
But either way, it would be similarly easy for a client to define
another class which implements both SegmentAllocator and
AutoCloseable, which wraps an Arena.<br>
<blockquote type="cite" cite="mid:DB7PR07MB5499C8EA98AD38020AE19E9CE0389@DB7PR07MB5499.eurprd07.prod.outlook.com">
<div class="WordSection1">
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">If memory session will not have close()
method, I can close session only using Arena close() method.</p>
</div>
</blockquote>
Yes.<br>
<blockquote type="cite" cite="mid:DB7PR07MB5499C8EA98AD38020AE19E9CE0389@DB7PR07MB5499.eurprd07.prod.outlook.com">
<div class="WordSection1">
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">However in case in pooling areana, I would
have one “shared” arena – responsible for allocating native
segments and it’s session will be long living session
associated with pool.</p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I would have to create number of child
arenas. This would mean that PoolingArena has to track
dependencies between arenas on their own, and preventing
closing Pool when there’s at least single child arena alive.</p>
</div>
</blockquote>
<p>I did some experiments with your pooled allocator - and there are
two possible approaches, both of which work:</p>
<p>* the pool can take an external session, and create new unsafe
segments that "alias" some memory in the pool, associated with the
external session. When creating the unsafe segments you would pass
a cleanup action to "return" the segments back to the pool.<br>
* the pool can take no session and return a _new_ (confined)
arena, which is used by clients to allocate new segments using the
pool - when the arena is closed, all the memory is returned back
to the pool.</p>
<p>In my experiments, the latter approach seems to give slightly
better performance - but that's mostly a choice for the pool API.<br>
</p>
<p>As in previous releases (e.g. Java 19), there is no explicit
mechanism to keep the pool alive when there's an allocator active
- but this can easily be worked around by having the pool memory
be managed by an implicit session.</p>
<p>When we'll get to nested session (either structured or
unstructured) there will be more ways for the pool to verify that
the external session/created arena feature the correct lifetime
dependencies.</p>
<p>I hope this helps.</p>
<p>Maurizio<br>
</p>
<blockquote type="cite" cite="mid:DB7PR07MB5499C8EA98AD38020AE19E9CE0389@DB7PR07MB5499.eurprd07.prod.outlook.com">
<div class="WordSection1">
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Am I’m correct?</p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Kind regards,</p>
<p class="MsoNormal">Radoslaw Smogura</p>
<p class="MsoNormal"><o:p> </o:p></p>
<div style="mso-element:para-border-div;border:none;border-top:solid
#E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="border:none;padding:0in"><b>From:
</b><a href="mailto:maurizio.cimadamore@oracle.com" moz-do-not-send="true">Maurizio Cimadamore</a><br>
<b>Sent: </b>Wednesday, November 2, 2022 10:47 PM<br>
<b>To: </b><a href="mailto:panama-dev@openjdk.java.net" moz-do-not-send="true" class="moz-txt-link-freetext">panama-dev@openjdk.java.net</a><br>
<b>Subject: </b>Re: dissecting memory sessions</p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">In case you are interested, below are some
more pointers.<br>
<br>
First, the javadoc which contains the proposed FFM API
changes:<br>
<br>
<a href="http://cr.openjdk.java.net/~mcimadamore/panama/session_handle_hidden_javadoc/javadoc/java.base/java/lang/foreign/package-summary.html" moz-do-not-send="true" class="moz-txt-link-freetext">http://cr.openjdk.java.net/~mcimadamore/panama/session_handle_hidden_javadoc/javadoc/java.base/java/lang/foreign/package-summary.html</a><br>
<br>
For those of you who are more interested at the code, here is
the branch <br>
that contains the code changes:<br>
<br>
<a href="https://urldefense.com/v3/__https://github.com/mcimadamore/panama-foreign/tree/session_drop_min__;!!ACWV5N9M2RV99hQ!IOtRU7vEmPqOt8IlQJvzJ7Boallwz_44pR4uQkJ-u5_wZG6TT999TwsvbndQKDkCTJvl7z2dScp3Y0u7FMxKIg$" moz-do-not-send="true">https://github.com/mcimadamore/panama-foreign/tree/session_drop_min</a><br>
<br>
And, finally, here is also a jextract branch that supports the
proposed <br>
FFM API changes:<br>
<br>
<a href="https://urldefense.com/v3/__https://github.com/mcimadamore/jextract/tree/panama_session_refresh__;!!ACWV5N9M2RV99hQ!IOtRU7vEmPqOt8IlQJvzJ7Boallwz_44pR4uQkJ-u5_wZG6TT999TwsvbndQKDkCTJvl7z2dScp3Y0uDZ9JQxw$" moz-do-not-send="true">https://github.com/mcimadamore/jextract/tree/panama_session_refresh</a><br>
<br>
Cheers<br>
Maurizio<br>
<br>
On 02/11/2022 17:48, Maurizio Cimadamore wrote:<br>
> Hi,<br>
> After the first preview of the FFM API in Java 19, we
have identified <br>
> a couple of areas where the API could use some
improvements:<br>
><br>
> * Clarify the relationship between MemorySegment and
MemoryAddress <br>
> (this 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 <br>
> libraries to protect against "sneaky" close, by creating
non-closeable <br>
> memory session views.<br>
><br>
> After staring at this problem long enough, it became
increasingly <br>
> clear that memory sessions, in their current shape and
form, are <br>
> trying to do too much - from allocation, to lifecycle
management and <br>
> more. The issue with "sneaky" close is mostly a
manifestation of that <br>
> more fundamental problem. In that spirit, we have put
together a <br>
> document which teases apart the various "traits"
associated with <br>
> memory sessions, and repackages the same traits into an
API that <br>
> provides better encapsulation and composition. The
document can be <br>
> found here:<br>
><br>
> <a href="http://cr.openjdk.java.net/~mcimadamore/panama/session_arenas.html" moz-do-not-send="true" class="moz-txt-link-freetext">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 <br>
> by a *second* abstraction, called Arena. Crucially, an
Arena _has_ a <br>
> memory session, which can e.g. be used to allocate
segments that have <br>
> the same lifecycle as that of the arena. This subtle
twist, gives us <br>
> an API that is easier to reason about (and to build
upon), and one <br>
> where memory segments can be shared freely across clients
- premature <br>
> calls to MemorySession::close are no longer possible. At
the same <br>
> time, the API now makes a much clearer distinction
between sessions <br>
> that are closeable (i.e. sessions created through an
Arena) and those <br>
> 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 <br>
> clients 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] - <br>
> <a href="https://cr.openjdk.java.net/~mcimadamore/panama/segment_address.html" moz-do-not-send="true" class="moz-txt-link-freetext">
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" moz-do-not-send="true" class="moz-txt-link-freetext">
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" moz-do-not-send="true" class="moz-txt-link-freetext">
https://mail.openjdk.org/pipermail/panama-dev/2022-February/016152.html</a><br>
><br>
><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</blockquote>
</body>
</html>