<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><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">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">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>