RFR: 8254162: Implementation of Foreign-Memory Access API (Third Incubator) [v6]

[Maurizio Cimadamore]

On Mon, 12 Oct 2020 18:06:55 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Build changes look good.
>
> I've just uploaded a biggie update to the foreign memory access support. While doing performance evaluation, we have
> realized that mixing a multi-level hierarchy (`MappedMemorySegment extends MemorySegments`) with exact invoke semantics
> of `VarHandle` and `MethodHandle` is not a good match and can lead to great performance degradation for seemingly
> "correct" code.  While some of this can be attributed to the `VarHandle` API, or to the fact that the so called
> "generic" invocation path should not be that slow in case where the parameters are clearly related, it seems smelly
> that a primitive API such as `MemorySegment` should give raise to such issues.  We have therefore decided to drop the
> `MappedMemorySegment` - this means that there's only one memory segment type users can deal with: `MemorySegment` - and
> no chance for mistakes. Of course `MappedMemorySegment` has been primarily introduces to allow for operations which
> were previously possible on `MappedByteBuffer` such as `force`. To support these use cases, a separate class has been
> introduced, namely `MappedMemorySegments` (note the trailing `S`). This class contains a bunch of static methods which
> can be used to achieve the desired effects, without polluting the `MemorySegment` API.  A new method has been added on
> `MemorySegment` which returns an optional file descriptor; this might be useful for clients which want to guess whether
> a segment is in fact a mapped segment, or if they need (e.g. in Windows) the file descriptor to do some other kind of
> low level op.  I think this approach is more true to the goals and spirit of the Foreign Memory Access API, and it also
> offers some ways to improve over the existing API: for instance, the only reason why the `MemorySegment::spliterator`
> method was a static method was that we needed inference, so that we could return either a `Spliterator<MemorySegment>`
> or a `Spliterator<MappedMemorySgement>`. All of that is gone now, so the method can return to be what it morally always
> has been: an instance method on `MemorySegment`.  Updated javadoc:
> http://cr.openjdk.java.net/~mcimadamore/8254162_v2/javadoc/jdk/incubator/foreign/package-summary.html  Updated
> specdiff: http://cr.openjdk.java.net/~mcimadamore/8254162_v2/specdiff/overview-summary.html

The latest iteration addresses a comment raised during CSR review; more specifically, the `MemoryAccess` class has
several variants of dereference methods - e.g. `getInt`, `getInt_LE`, `getInt_BE`, to support different endianness. The
comment was to just have two overloads, e.g. `getInt` and `getInt(ByteOrder)` instead of three. I've implemented the
suggestion in this new iteration, as I think it makes the API a bit more compact.

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

PR: https://git.openjdk.java.net/jdk/pull/548