Split MappedMemorySegment out of the hierarchy

[Maurizio Cimadamore]

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

I think before we propose solutions it would be good to agree on what is 
the problem that we're trying to solve.

MemorySegment has 5 methods that are related to "mappings":

* isMapped()
* load()
* isLoaded()
* force()
* unload()

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).

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).

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.

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.

Maurizio


On 06/12/2022 17:03, Quân Anh Mai wrote:
> Hi,
>
> 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.
>
> Thanks,
> Quan Anh
>
> On Wed, 7 Dec 2022 at 00:54, Maurizio Cimadamore 
> <maurizio.cimadamore at oracle.com> wrote:
>
>     Hi,
>     we have considered this approach - but it creates some
>     asymmetries. For
>     instance, the Spliterator method has to feature covariant return, etc.
>
>     Also, if you have a subclass of memory segment, it means that cast
>     would
>     have to be inserted when interacting with downcall method handles.
>
>     On balance, you get a marginal API simplification, but not clear
>     to me
>     that it's worth it.
>
>     Another directon I've been thiking about lately is whether we need
>     mapped segments at all - e.g. the semantics of load()/force() etc. is
>     completely OS-specific (most of these methods are no-op on windows).
>
>     While these methods used to make sense on MappedByteBuffer - are
>     we sure
>     they still make sense for memory segments? Wouldn't an advanced
>     client
>     using the FFM API prefer to use its own way to "force" mapped
>     segments,
>     using system-specific primitives?
>
>     Maurizio
>
>     On 06/12/2022 16:28, Quân Anh Mai wrote:
>     > Hi Panama experts,
>     >
>     > The MemorySegment interface has several methods dedicated to
>     > supporting MappedMemorySegment such as isMapped, load, etc. May
>     I ask
>     > if we can make it become a separate class that contains a
>     > NativeMemorySegment instead, and make the dedicated methods
>     members of
>     > the encompassing class instead? I have taken a look at
>     > MappedMemorySegment and it seems that the only other methods that
>     > need to be mappedness-specific are asSlice and makeByteBuffer.
>     And in
>     > that case, we can make asSlice and makeByteBuffer also methods
>     for the
>     > encompassing class, too.
>     >
>     > This may make the interface clearer by not overloading
>     MemorySegment
>     > with methods that it is not really capable of, and also helps
>     the JIT
>     > to emit more optimised code for other operations with a more
>     > restricted hierarchy.
>     >
>     > Thanks a lot for your reading and I really appreciate your
>     responses.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/panama-dev/attachments/20221206/47aa3b4d/attachment.htm>