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

[Maurizio Cimadamore]

Hi
Some of you might wonder as to why the API in this JEP is "still" 
incubating, and what the exit criteria from incubation are. This is, we 
think, a valid point, and one which we'd like to clarify/address a bit here.

First, while it's true that the API has improved considerably over the 
last couple of years, we believe the changes described in this latest 
JEP constitute, to date, the best effort to capture all the moving part 
when it comes to managing off-heap memory. The addition of the new 
ResourceScope/SegmentAllocator abstractions has been instrumental in 
order to address several issues in the previous iterations of the API. 
As with all biggie API changes, there is a source compatibility price to 
pay; I believe this iteration has a much higher chance to break existing 
code written against the Foreign Memory Access API (for one, 
MemorySegment is no longer an AutoCloseable). Because of this, it seemed 
sensible to give them a bit more bake time, rather than declaring it done.

Secondly, there's the issue of VM optimizations; while a lot of work has 
been done in this area, there are still two ways in which the VM support 
for the Foreign Function and Memory API lags behind. Optimization of 
long loops, while improved, still doesn't contain certain bits which are 
crucial to make memory segment access fast [1]. Without those, clients 
are forced to workaround some of the issues, by using `int` (and then 
cast things back to `long`), which is cumbersome and, we feel, way too 
sharp for a "final" API. And, while this iteration vastly improves 
support for upcalls (calling Java from native code), in general the 
linker support is still missing intrinsification support in few 
important cases, such as when arguments are spilled on the stack [2]. 
While this is not rocket science, it's more work that needs to be done, 
so that user can enjoy a predictable performance model, both when 
accessing off-memory, and when calling native functions.

Lastly, while the concept of restricted methods has been present in 
previous JEPs, this JEP is the first one which adds a new launcher 
option for it (--enable-native-access). While the impact on clients 
should be limited (after all, even before some command line option was 
required - e.g. `-Dforeign.restricted=permit`), we feel that this is a 
big enough change to warrant for another round of incubation, to make 
sure that the new option is working as expected. There is also more work 
to be done there, to integrate support for restricted methods in javadoc 
(so that restricted methods are rendered in a special way, similarly to 
preview methods) which we won't be able to fully deliver in 17.

So, while we understand that there might be a desire to move things 
forwards, we felt moving to preview (or finalize the API) at this point 
would have been simply premature.

Cheers
Maurizio


[1] - https://bugs.openjdk.java.net/browse/JDK-8259609
[2] - https://bugs.openjdk.java.net/browse/JDK-8255902


On 22/04/2021 19:27, mark.reinhold at oracle.com wrote:
> https://openjdk.java.net/jeps/412  > > 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