New candidate JEP: 412: Foreign Function & Memory API (Incubator)
maurizio.cimadamore at oracle.com
Fri Apr 23 14:49:51 UTC 2021
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 . 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 .
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.
 - https://bugs.openjdk.java.net/browse/JDK-8259609
 - 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
More information about the jdk-dev