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