<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">On 16/09/2022 19:09, Manuel
Bleichenbacher wrote:<br>
</div>
<blockquote type="cite" cite="mid:CAA7F5jK0iD+qxhGPj64sNSun2BZFbc88ZpL-qQU73=wgnqT9kA@mail.gmail.com">
<div dir="ltr">Thank you Maurizio.
<div><br>
</div>
<div>It works very well and I've integrated it in my code.</div>
<div><br>
</div>
<div>Now that I have some insights into the implementation, I
can understand why it works.</div>
<div><br>
</div>
<div>But initially I expected that a memory segment is either
allocated and available, or deallocated and not available. And
when I learned that it can be closed before it is eventually
freed, I expected that it cannot be accessed in that state,
neither through it's original nor any other session. It's
still a bit surprising. I hope it's not an implementation
detail that will change one day.</div>
</div>
</blockquote>
<p>Well, the segment is inaccessible after it's closed. But you can
still get its address and _unsafely_ create a new segment at that
address.</p>
<p>The API I suggested is playing on the ordering of close action,
to allow clients to take a final stab at the segment before it
goes away for good.</p>
<p>In general I think it will be hard to shy away from some kind of
LIFO ordering of close action because if your code created 3
structs where the second depends on the first, and the third
depends on the second, it is quite natural to add close action for
the first, then second, then third, and expect (at least if they
have been added in the same thread) that they will be called in
reversed order.</p>
<p>That said, I can also see how relying on ordering too much could
quickly lead to "magic" code that is harder to read.</p>
<p>Maurizio<br>
</p>
<blockquote type="cite" cite="mid:CAA7F5jK0iD+qxhGPj64sNSun2BZFbc88ZpL-qQU73=wgnqT9kA@mail.gmail.com">
<div dir="ltr">
<div><br>
</div>
<div>-- Manuel</div>
<div><br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Thu, Sep 15, 2022 at 7:47
PM Maurizio Cimadamore <<a href="mailto:maurizio.cimadamore@oracle.com" moz-do-not-send="true" class="moz-txt-link-freetext">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">
<div>
<p><br>
</p>
<div>On 15/09/2022 18:06, Manuel Bleichenbacher wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>Thank you for the detailed answer.</div>
<div><br>
</div>
<div>It's quite confusing that the segment can still be
copied but not used in a method call. To understand
it, it either requires detailed knowledge about the
implementation or a new concept or state related to
session and segments must documented.</div>
</div>
</blockquote>
<p>Note that by "copied" we're probably referring to
different things.</p>
<p>What I meant by "copying" was doing this:</p>
<p>```<br>
assertFalse(oldSegment.session().isAlive());<br>
MemorySegment newSegment =
MemorySegment.ofAddress(oldSegment.address(),
oldSegment.byteSize(), globalSession());<br>
// now I can use newSegment!<br>
```</p>
<p>The `ofAddress` factory creates a new native segment
(unsafely), with a given base address, size and session.
It does not copy any contents, it just assumes that the
base address you provide is correct.</p>
<p><br>
</p>
<blockquote type="cite">
<div dir="ltr">
<div><br>
</div>
<div>Anyway, this would be even more cumbersome. So I'm
sticking to other approaches for cleanup.</div>
</div>
</blockquote>
<p>One approach worth considering could be to also add an
`addCloseAction` method on `MemorySegment` which basically
is syntactic sugar for the code above: <br>
</p>
<p>```<br>
void addCloseAction(Consumer<MemorySegment> action)
{<br>
</p>
Runnable action = () -> {<br>
try (MemorySession closingSession =
MemorySession.openConfined()) {<br>
MemorySegment dup =
MemorySegment.ofAddress(this.address(), this.byteSize(),
closingSession);<br>
action.accept(dup);<br>
} <br>
}<br>
session.addCloseAction(action);<br>
}<br>
<p>```</p>
<p>If you have this method, then you can just do:</p>
<p>```<br>
MemorySegment segment = MemorySegment.allocateNative(100,
...);<br>
segment.addCloseAction( segment -> <insert logic
here>);<br>
```</p>
<p>Note that the segment the lambda operates on is not
exactly the same segment as the original (it has a
different memory session), but it is backed by the same
memory region. Since we can guarantee that this custom
cleanup action will always run _before_ the "free"/"unmap"
operation (even in the case of multple threads), this
would effectively solve some of the issues you brought up.
Is that something that would be helpful? Perhaps you could
try adding a method like the above in your code, but as a
static method like this (since the implementation just
relies on public API):</p>
<p>```<br>
</p>
<pre style="background-color:rgb(255,255,255);color:rgb(0,0,0);font-family:"Source Code Pro",monospace;font-size:11.3pt"><span style="color:rgb(0,0,128);font-weight:bold">static void </span>addCloseAction(MemorySegment segment, Consumer<MemorySegment> action) {
<span style="color:rgb(0,0,128);font-weight:bold">long </span>size = segment.byteSize();
<span style="color:rgb(0,0,128);font-weight:bold">long </span>address = segment.address(); <span style="color:rgb(128,128,128);font-style:italic">// or use MemoryAddress if on Java 19
</span><span style="color:rgb(128,128,128);font-style:italic"> </span>Runnable closeAction = () -> {
<span style="color:rgb(0,0,128);font-weight:bold">try </span>(MemorySession closingSession = MemorySession.<span style="font-style:italic">openConfined</span>()) {
MemorySegment dup = MemorySegment.<span style="font-style:italic">ofAddress</span>(<span style="color:rgb(102,14,122)">address</span>, <span style="color:rgb(102,14,122)">size</span>, closingSession);
<span style="color:rgb(102,14,122)">action</span>.accept(dup);
}
};
segment.session().addCloseAction(closeAction);
}</pre>
<p>```</p>
<p>And maybe you can let us know how that goes?</p>
<p>Thanks<br>
Maurizio<br>
</p>
<p><br>
</p>
<br>
<blockquote type="cite">
<div dir="ltr">
<div><br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Wed, Sep 14, 2022
at 11:59 PM Maurizio Cimadamore <<a href="mailto:maurizio.cimadamore@oracle.com" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">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"><br>
On 14/09/2022 22:28, Manuel Bleichenbacher wrote:<br>
> The documentation for
MemorySession.addCloseAction() states that the <br>
> order of custom cleanup actions is unspecified.
But it only hints at <br>
> the order of custom close actions vs. closing
memory segments.<br>
><br>
> Is it correct that memory segments are closed
first, and then the <br>
> custom cleanup actions are executed?<br>
><br>
> If so, is there a specific reason for it? It
would be more useful to <br>
> other way round.<br>
><br>
> I have several cases requiring cleanup of data
structures residing in <br>
> a memory segment. It would be most natural to use
custom cleanup <br>
> actions to do so as their lifespans end at the
same time. But given <br>
> the current order, a far less elegant way is
needed.<br>
<br>
The current spec says no ordering.<br>
<br>
In reality there is an ordering that can be relied
upon (the javadoc <br>
will likley be rectified to reflect this).<br>
<br>
The actions added to the scope last will also be
called first. Of course <br>
the ordering is only valid for actions added within
the same thread, and <br>
if you have multiple threads adding action, other
orders could be observed.<br>
<br>
When you allocate a memory segment using a session, a
cleanup action for <br>
it is added to the session (as if calling
addCloseAction), so you need <br>
to take that into account as well.<br>
<br>
Given all this, if you do:<br>
<br>
```<br>
MemorySegment.allocateNative(100, session);<br>
session.addCloseAction(runnable);<br>
```<br>
<br>
I would expect the "runnable" to be executed before
"free" is called on <br>
the memory segment.<br>
<br>
But, mind you, that alone won't help much: from the
perspective of the <br>
close action, the session attached to the segment has
already been <br>
closed, so you cannot touch the segment directly (by
the same token that <br>
protects from use after free). In other words, a
session is a bit of <br>
state that is shared by all the resources attached to
that session. When <br>
the session is closed (using the close() method), all
the resources <br>
attached to that session becomes inaccessible at once.
There's no way to <br>
add a "pre-close" action, because, if the action is
pre-close, the <br>
session is still alive, and it means that other
threads have potentially <br>
still access on the segment, and they might not know
the segment is <br>
about to be closed (so the close action would race
with other accesses, <br>
which seems a recipe for disaster).<br>
<br>
But the cleanup action can create a copy of the
segment into a fresh <br>
segment associated with the global scope (using <br>
MemorySegment::ofAddress), and access that instead
(since it knows the <br>
address still valid).<br>
<br>
Maurizio<br>
<br>
<br>
<br>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
</body>
</html>