On Mon, 12 Oct 2020 18:06:55 GMT, Maurizio Cimadamore <mcimadam...@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
