[foreign-memaccess] RFR: 8254343: Revisit API for supporting mapped memory segments

[Maurizio Cimadamore]

On Fri, 9 Oct 2020 21:10:05 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> As I was polishing the memory access API ahead of the upstream integration, I realized of a fatal flaw with the
> `MemorySegment` vs. `MappedMemorySegment` split. This split works against the idiomatic usage of the VarHandle API:
> since memory access var handles feature a `MemorySegment` coordinate, clients using a `MappedMemorySegment` will be
> using *inexact* access mode (which goes through an extra, expensive `asType` adaptation).   The only way to remove the
> perfomance issue is to make deep changes in the VarHandle machinery to support a more lax form of `asType` adaptation,
> but adding this to support mapped segments seems, frankly, overkill.  On top of that, while discussing this with Paul,
> I realized that no liveness check was performed on the load()/unload() operation, and that these operations, more
> generally, did not get the `@Scoped` treatment, meaning they will crash the VM when  used with shared segments.  This
> patch rectifies these issues; it removes the `MappedMemorySegment` interfaces, and it introduce a `MemoryMapping`
> abstraction instead. Clients can ask a memory mapping out of a segment; the memory mapping will contain the usual
> `load`/`force` operation, so there's no loss in expressiveness of the API.  For instance, to force contents of a mapped
> segment to be written in the underlying file, a client can do:  segment.asSlice(20, 100)
>        .mapping()
>        .ifPresent(MemoryMapping::force);
> 
> We believe this to be a reasonable compromise, which allows us to keep a single MemorySegment interface (instead of
> two), which removes the var handle performance issue, and in turn enables other improvements, such as turning the
> `spliterator` method into a true instance method.

Thanks for the experiments @JornVernee. I'd like to bring back the focus on the existing PR, as I think the problem of
direct var handle calls, and the issue at hands, while related, are slightly orthogonal. The question, for now (and
also in perspective for upstream integration) is: how do we intend to support mapped segments? There are few ways to do
that:

1. Keep the existing hierarchy - e.g. have a MappedMemorySegment which has more "powers" and operations (e.g. `force`).
This works, but leads users down the wrong usage of var handles/method handles.

2. Use a different trick (as this PR is attempting to do) to add support for certain mapped segment operations

3. Do nothing - mapped segments are just "native segments". If users want to force()/load()/... they will be able to do
that using the foreign linker API; after all, even the current support for some of these operations is crippled (and
this is not a `MemorySegment`-specific consideration, as it also holds true for the `ByteBuffer` API), as things stand
(and always has been) - e.g. as noted in another thread:

JNIEXPORT void JNICALL
Java_java_nio_MappedMemoryUtils_load0(JNIEnv *env, jobject obj, jlong address,
                                     jlong len)
{
    // no madvise available
}

So, one might argue that the memory segment API doesn't really need any special API for mapped segment; if you want to
do `force()`, and don't want to use the foreign linker API, you can just do:

((MappedByteBuffer)segment.asByteBuffer()).force();

And keep the existing semantics of the `force` operation (good or bad, depending on the system). What power-user are
likely to do is, instead, to declare a bunch of supporting foreign linker method handles (e.g. madvise, mlock and such
on Linux, and something else on Windows) which allow them to control the mapped memory _exactly_ the way they want,
without the added constraint of having to support a seemingly *platform neutral* API.

But as things stand, the status quo (1) seems unbalanced.

-------------

PR: https://git.openjdk.java.net/panama-foreign/pull/377