FFM API: Simplifying MemorySegment::ofBuffer

[Ioannis Tsakpinis]

Hello again,

In the context of writing a "compatibility" layer between JNI/NIO-based
bindings and FFM-based bindings, a method that seems problematic while
performance testing is MemorySegment::ofBuffer. Specifically, it is too
big to be inlined in most call-sites, which hurts optimizations in the
surrounding code.

(like my previous thread, this is mostly related to EA not scalar
replacing very-short-lived instances created behind the public API)

I don't have a benchmark to share, nor have I tested potential fixes,
but looking at the implementation, the first thing I would try is to
extract the HeapMemorySegmentImpl switch to a separate method and also
combine it with the getScaleFactor switch for that case. Right now the
type-switch happens twice, for no apparent benefit. While the types are
different, the result is effectively always the same. Then, I'd remove
the "The provided heap buffer is not backed by an array." check at the
start. Afaict, it is not something that could ever happen, at least not
without someone doing nasty things with Unsafe. These two changes
should make the method small enough for more inlining possibilities.

A more involved approach, but one that would definitely be more
efficient, is to move the MemorySegment creation to the NIO API
instead. MemorySegment::asByteBuffer is simple, because each segment
subclass knows exactly what kind of ByteBuffer to create. Likewise,
each Buffer subclass could have a method (non-public, exposed via
NIO_ACCESS or something) that creates the appropriate MemorySegment
subclass. For example, a direct DoubleBuffer would implicitly know to
create a NativeMemorySegmentImpl with a scale factor of 8.

Note that this is a low-priority request, just a small improvement that
would be good to have, but can live without. The motivation is being
able to run current LWJGL using FFM internally and without Unsafe
(prototype with --sun-misc-unsafe-memory-access=deny actually works!),
while providing decent performance compared to the legacy solution.
Future versions however will be 100% FFM-based, so not affected by this
issue at all.

- Ioannis