JEP 370 Feedback

[Henry Jen]

I am not sure I get what you trying to achieve. If you are thinking of using MemorySegment in native code(JNI code), it seems redundant to me. Since you are in native land, the memory access is all native handling, it’s not an issue.

To pass back a native address back into Java land, there is MemoryAddress.ofLong(), which will convert a long value to be an MemoryAddress in java. Basically, you are dealing with pointer as usual in JNI code, but you can use Memory access API to access native memory in Java code.

So, in short, NewDirectByteBuffer(addr, size) can be replaces with 
Foreign.withSize(MemoryAddress.ofLong(addr), size).segment().asByteBuffer().

It is not as straightforward, but I don’t think there is a good reason to change JNI interface with foreign-abi APIs coming.

Hope that helps.

Cheers,
Henry


> On Apr 20, 2020, at 12:36 PM, Philippe Marschall <kustos at gmx.net> wrote:
> 
> 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