JEP 370 Feedback

[Philippe Marschall]

Hello

I'm not sure whether this is the right channel. I had a quick look at
JEP 370 and since it's an incubator feature I wanted to take the
opportunity to provide some feedback:

The biggest limitation I'm currently seeing is the missing ability to
deal with MemorySegment on the native / JNI side. Mainly I'm missing
equivalents of the following JNI functions:

- NewDirectByteBuffer
- GetDirectBufferAddress
- GetDirectBufferCapacity

These functions are required when:

- libraries expect memory to be allocated and released using library
specific functions
- allocations need to happen with specific flags currently not supported
by the JDK
- a native thread calls into Java code

Yes, this can be achieved by going through a ByteBuffer, however this
has the following disadvantages:

- a DirectByteBuffer has to be allocated which is noticeable for small
allocations
- no timely release of memory through try-with-resources, instead a
custom native method has to be provided and called

Should these be added it would be helpful if the equivalent of
NewDirectByteBuffer would take a function pointer to a release function
and optionally an attachment which will be called by MemorySegment#close().

How would incubator features be made available to JNI code? Through a
#define? Through a different header?

What would also be helpful is the ability to efficiently convert a
MemorySegment to a Java String without an intermediate byte[] or a NIO
Buffer used by a Charset.

I had a quick, unscientific look at performance compared to
malloc/calloc/free with NewDirectByteBuffer and it looks as if the
performance of JEP 370 compares favorably. Were I did find a performance
deficit was when comparing with large allocations using mmap and large
pages, either single threaded or multi-threaded with the allocation size
matching the page size (2M). This is not unexpected.

Cheers
Philippe