New candidate JEP: 419: Foreign Function & Memory API (Second Incubator)

[Sebastian Stenzel]

> On 12. Oct 2021, at 12:03, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
> 
> On 12/10/2021 07:00, Sebastian Stenzel wrote:
>> [...]
>> 
>> First of all, regarding `allocateNative`, I think it should be explicitly stated that allocation does not mean initialization. [...]
> Except that allocateNative does zero the memory :-) There are some obscure flags by which you can disable this, but in general that's the lay of the land. If a more optimized allocator is needed, a SegmentAllocator is probably the way to go, in which there's more freedom as to how memory is actually allocated/inited. Note that ByteBuffer.allocateDirect also does memory zeroing.

Oh well... good to know! :D

While my assumption was wrong, the conclusion stays the same: It should be mentioned whether we can rely on one or the other behaviour.

>> 
>> Furthermore, here are my two cents about the `setUtf8String` JavaDoc. Currently it says:
>> 
>>> Writes a UTF-8 encoded, null-terminated string into this segment at given offset.
>> ... which, being nit-picky, I read as "please pass a UTF-8 encoded, null terminated string to this method". Instead, I'd suggest:
>> 
>>> Writes the given string into this segment at given offset, converting it to a null-terminated byte sequence using UTF-8 encoding.
> Sounds good.

Does this require me opening an issue or is there a less formal way of changing it?

>> Last but not least, I'd like to note that the size of the allocated segment in the aforementioned example depends on the string length (should be `length()`), which is inaccurate when using multi-byte unicode code points. Just thought, I'd mention it, as people may copy this code.
> 
> This is all true but.... let me put the example in context:
> 
> * that's the first example in the JEP
> * the goal of that example is to give a "feel" of what the API can do (you will see there's a lot of sections with "..." in them) - copy and paste won't work
> * in principle, it's easier to just use an allocator to allocate AND initialize a Utf8 native string with null termination; but allocators felt too much for this first example
> * if you scroll down, there's a more detailed example on how to call strlen - and that does use an implicitAllocator
> 
> The alternative is to replace the snippet with:
> 
> implicitAllocator().allocateUtf8String(javaStrings[i]);
> 
> Perhaps we might just do that (in the earlier iteration we did not have a constant for that allocator).
> 
> Maurizio

Fair enough, I just thought I'd mention it, while I'm on it. ;-)

> 
>> 
>> 
>>> On 12. Oct 2021, at 00:41, mark.reinhold at oracle.com wrote:
>>> 
>>> https://openjdk.java.net/jeps/419
>>> 
>>>  Summary: Introduce an API by which Java programs can interoperate with
>>>  code and data outside of the Java runtime. By efficiently invoking
>>>  foreign functions (i.e., code outside the JVM), and by safely accessing
>>>  foreign memory (i.e., memory not managed by the JVM), the API enables
>>>  Java programs to call native libraries and process native data without
>>>  the brittleness and danger of JNI.
>>> 
>>> - Mark