Split MappedMemorySegment out of the hierarchy

[Maurizio Cimadamore]

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.