<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p>This seems even more complex. Now we have two unrelated types
MemorySegment and MappedMemorySegment(XYZ) [why isn't
MappedMemorySegment a MemorySegment], which feature
similarly-looking methods...</p>
<p>I think before we propose solutions it would be good to agree on
what is the problem that we're trying to solve.</p>
<p>MemorySegment has 5 methods that are related to "mappings":</p>
<p>* isMapped()<br>
* load()<br>
* isLoaded()<br>
* force()<br>
* unload()</p>
<p>By lumping native segments and mapped segments together (like BB
does), we guarantee that mapped segments can be passed around just
as if they were native segments (which they are). <br>
</p>
<p>Result of the lumping is that the operations become partial. But
these operations are so rare (and as I said, so not well supported
across platforms), that I wonder why (a) why is this a big issue
and (b) if these operations really add confusion to the API, why
not removing them, since there are alternatives (Linker, or going
to MappedByteBuffer).</p>
<p>Adding a full-blown fist-class abstraction just for these methods
(which I posit are used in 1% of times - because of the
aforementioned problmes) seems like the wrong approach to me.</p>
<p>It is also rather important that, no matter what buffer you have,
you can create a segment out of it - so if your container is NOT a
segment, MemorySegment::ofBuffer would no longer work (or be
total). Which to me seems like _more_ complexity, not less.<br>
</p>
<p>Maurizio<br>
</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 06/12/2022 17:03, Quân Anh Mai
wrote:<br>
</div>
<blockquote type="cite" cite="mid:CAPvyiy+rA6=+zRKQE5_gtMxqYswzw8=Tz6woLv6gUcuViK1mjQ@mail.gmail.com">
<div dir="ltr">Hi,
<div><br>
</div>
<div>What I mean is that to make MappedMemorySegment(Container)
a separate hierarchy that contains a data segment, other
operations will be performed through this.data apart from
makeByteBuffer and asSlice which will be separate from that of
a MemorySegment (i.e. this.data.asSlice will return a normal
segment that acts similar to any other kind of memory, while
this.asSlice will return a MappedMemorySegment(Container). I
believe this situation can be seen as similar to an Arena
which can allocate and deallocate memory, which contains a
scope which can be used to keep track of the memory lifetime.</div>
<div><br>
</div>
<div>Thanks,</div>
<div>Quan Anh</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Wed, 7 Dec 2022 at 00:54,
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">Hi,<br>
we have considered this approach - but it creates some
asymmetries. For <br>
instance, the Spliterator method has to feature covariant
return, etc.<br>
<br>
Also, if you have a subclass of memory segment, it means that
cast would <br>
have to be inserted when interacting with downcall method
handles.<br>
<br>
On balance, you get a marginal API simplification, but not
clear to me <br>
that it's worth it.<br>
<br>
Another directon I've been thiking about lately is whether we
need <br>
mapped segments at all - e.g. the semantics of load()/force()
etc. is <br>
completely OS-specific (most of these methods are no-op on
windows).<br>
<br>
While these methods used to make sense on MappedByteBuffer -
are we sure <br>
they still make sense for memory segments? Wouldn't an
advanced client <br>
using the FFM API prefer to use its own way to "force" mapped
segments, <br>
using system-specific primitives?<br>
<br>
Maurizio<br>
<br>
On 06/12/2022 16:28, Quân Anh Mai wrote:<br>
> Hi Panama experts,<br>
><br>
> The MemorySegment interface has several methods dedicated
to <br>
> supporting MappedMemorySegment such as isMapped, load,
etc. May I ask <br>
> if we can make it become a separate class that contains a
<br>
> NativeMemorySegment instead, and make the dedicated
methods members of <br>
> the encompassing class instead? I have taken a look at <br>
> MappedMemorySegment and it seems that the only other
methods that <br>
> need to be mappedness-specific are asSlice and
makeByteBuffer. And in <br>
> that case, we can make asSlice and makeByteBuffer also
methods for the <br>
> encompassing class, too.<br>
><br>
> This may make the interface clearer by not overloading
MemorySegment <br>
> with methods that it is not really capable of, and also
helps the JIT <br>
> to emit more optimised code for other operations with a
more <br>
> restricted hierarchy.<br>
><br>
> Thanks a lot for your reading and I really
appreciate your responses.<br>
</blockquote>
</div>
</blockquote>
</body>
</html>