JEP 454: Foreign Function & Memory API

OwnerMaurizio Cimadamore
TypeFeature
ScopeSE
StatusCandidate
Componentcore-libs / java.lang.foreign
Discussionpanama dash dev at openjdk dot org
Reviewed byAlex Buckley, Jorn Vernee
Created2023/06/22 09:36
Updated2023/09/11 20:17
Issue8310626

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.

History

The Foreign Function & Memory (FFM) API was originally proposed as a preview feature by JEP 424 (JDK 19) and subsequently refined by JEPs JEP 434 (JDK 20) and JEP 442 (JDK 21). This JEP proposes to finalize the FFM API with further small refinements based upon continued experience and feedback. In this version we have:

Goals

Non-goals

It is not a goal to

Motivation

The Java Platform has always offered a rich foundation to library and application developers who wish to reach beyond the JVM and interact with other platforms. Java APIs expose non-Java resources conveniently and reliably, whether to access remote data (JDBC), invoke web services (HTTP client), serve remote clients (NIO channels), or communicate with local processes (Unix-domain sockets). Unfortunately, Java developers still face significant obstacles in accessing an important kind of non-Java resource: code and data on the same machine as the JVM, but outside the Java runtime.

Foreign memory

Objects created via the new keyword are stored in the JVM's heap, where they are subject to garbage collection when no longer needed. However, the cost and unpredictability of garbage collection is unacceptable for performance-critical libraries such as Tensorflow, Ignite, Lucene, and Netty. They need to store data outside the heap, in off-heap memory which they allocate and deallocate themselves. Access to off-heap memory also allows data to be serialized and deserialized by mapping files directly into memory via, e.g., mmap.

The Java Platform has historically provided two APIs for accessing off-heap memory:

In summary, sophisticated clients deserve an API that can allocate, manipulate, and share off-heap memory with the same fluidity and safety as on-heap memory. Such an API should balance the need for predictable deallocation with the need to prevent premature deallocation, which can lead to JVM crashes or, worse, to silent memory corruption.

Foreign functions

JNI has supported the invocation of native code (i.e., foreign functions) since Java 1.1, but it is inadequate for many reasons.

Over the years, numerous frameworks have emerged to fill the gaps left by JNI, including JNA, JNR and JavaCPP. These frameworks are often a marked improvement over JNI but the situation is still less than ideal — especially when compared with languages which offer first-class native interoperation. For example, Python's ctypes package can dynamically wrap functions in native libraries without any glue code. Other languages, such as Rust, provide tools which mechanically derive native wrappers from C/C++ header files.

Ultimately, Java developers should have a supported API that enables them to straightforwardly consume any native library deemed useful for a particular task, without the tedious glue and clunkiness of JNI. Two excellent abstractions to build upon are method handles, which are direct references to method-like entities, and variable handles, which are direct references to variable-like entities. Exposing native code via method handles, and native data via variable handles, would radically simplify the task of writing, building, and distributing Java libraries which depend upon native libraries. Furthermore, an API capable of modeling foreign functions (i.e., native code) and foreign memory (i.e., off-heap data) would provide a solid foundation for third-party native interoperation frameworks.

Description

The Foreign Function & Memory API (FFM API) defines classes and interfaces so that client code in libraries and applications can

The FFM API resides in the java.lang.foreign package of the java.base module.

Example

As a brief example of using the FFM API, here is Java code that obtains a method handle for a C library function radixsort and then uses it to sort four strings which start life in a Java array (a few details are elided).

// 1. Find foreign function on the C library path
Linker linker          = Linker.nativeLinker();
SymbolLookup stdlib    = linker.defaultLookup();
MethodHandle radixsort = linker.downcallHandle(stdlib.find("radixsort"), ...);
// 2. Allocate on-heap memory to store four strings
String[] javaStrings = { "mouse", "cat", "dog", "car" };
// 3. Use try-with-resources to manage the lifetime of off-heap memory
try (Arena offHeap = Arena.ofConfined()) {
    // 4. Allocate a region of off-heap memory to store four pointers
    MemorySegment pointers
        = offHeap.allocateFrom(ValueLayout.ADDRESS, javaStrings.length);
    // 5. Copy the strings from on-heap to off-heap
    for (int i = 0; i < javaStrings.length; i++) {
        MemorySegment cString = offHeap.allocateFrom(javaStrings[i]);
        pointers.setAtIndex(ValueLayout.ADDRESS, i, cString);
    }
    // 6. Sort the off-heap data by calling the foreign function
    radixsort.invoke(pointers, javaStrings.length, MemorySegment.NULL, '\0');
    // 7. Copy the (reordered) strings from off-heap to on-heap
    for (int i = 0; i < javaStrings.length; i++) {
        MemorySegment cString = pointers.getAtIndex(ValueLayout.ADDRESS, i);
        javaStrings[i] = cString.reinterpret(...).getString(0);
    }
} // 8. All off-heap memory is deallocated here
assert Arrays.equals(javaStrings,
                     new String[] {"car", "cat", "dog", "mouse"});  // true

This code is far clearer than any solution that uses JNI, since the implicit conversions and memory accesses that would have been hidden behind native method calls are now expressed directly in Java code. Modern Java idioms can also be used; for example, streams can allow multiple threads to copy data between on-heap and off-heap memory in parallel.

Memory segments and arenas

A memory segment is an abstraction backed by a contiguous region of memory, located either off-heap or on-heap. A memory segment can be

All memory segments provide spatial and temporal bounds which ensure that memory access operations are safe. In a nutshell, the bounds guarantee no use of unallocated memory and no use-after-free.

The spatial bounds of a segment determine the range of memory addresses associated with the segment. For example, the code below allocates a native segment of 100 bytes, so the associated range of addresses is from some base address b to b + 99 inclusive.

MemorySegment data = Arena.global().allocate(100);

The temporal bounds of a segment determine its lifetime, that is, the period until the region of memory which backs the segment is deallocated. The FFM API guarantees that a memory segment cannot be accessed after its backing region of memory is deallocated.

The temporal bounds of a segment are determined by the arena used to allocate the segment. Multiple segments allocated in the same arena have the same temporal bounds, and can safely contain mutual references: Segment A can hold a pointer to an address in segment B, and segment B can hold a pointer to an address in segment A, and both segments will be deallocated at the same time so that neither segment has a dangling pointer.

The simplest arena is the global arena, which provides an unbounded lifetime: It is always alive. A segment allocated in the global arena, as in the code above, is always accessible and the region of memory backing the segment is never deallocated.

Most programs, though, require off-heap memory to be deallocated while the program is running, and thus need memory segments with bounded lifetimes.

An automatic arena provides a bounded lifetime: A segment allocated by an automatic arena can be accessed until the JVM's garbage collector detects that the memory segment is unreachable, at which point the region of memory backing the segment is deallocated. For example, this method allocates a segment in an automatic arena:

void processData() {
    MemorySegment data = Arena.ofAuto().allocate(100);
    ... use the 'data' variable ...
    ... use the 'data' variable some more ...
}  // the region of memory backing the 'data' segment
   // is deallocated here (or later)

As long as the data variable does not leak out of the method, the segment will eventually be detected as unreachable and its backing region will be deallocated.

An automatic arena's bounded but non-deterministic lifetime is not always sufficient. For example, an API that maps a memory segment from a file should allow the client to deterministically deallocate the region of memory backing the segment since waiting for the garbage collector to do so could adversely affect performance.

A confined arena provides a bounded and deterministic lifetime: It is alive from the time the client opens the arena until the time the client closes the arena. A memory segment allocated in a confined arena can be accessed only before the arena is closed, at which point the region of memory backing the segment is deallocated. Attempts to access a memory segment after its arena is closed will fail with an exception. For example, this code opens an arena and uses the arena to allocate two segments:

MemorySegment input = null, output = null;
try (Arena processing = Arena.ofConfined()) {
    input = processing.allocate(100);
    ... set up data in 'input' ...
    output = processing.allocate(100);
    ... process data from 'input' to 'output' ...
    ... calculate the ultimate result from 'output' and store it elsewhere ...
}  // the regions of memory backing the segments are deallocated here
...
input.get(ValueLayout.JAVA_BYTE, 0);  // throws IllegalStateException
                                      // (also for 'output')

Exiting the try-with-resources block closes the arena, at which point all segments allocated by the arena are invalidated atomically and the regions of memory backing the segments are deallocated.

A confined arena's deterministic lifetime comes at a price: Only one thread can access the memory segments allocated in a confined arena. If multiple threads need access to a segment then a shared arena can be used. The memory segments allocated in a shared arena can be accessed by multiple threads, and any thread — whether it accesses the region or not — can close the arena to deallocate the segments. Closing the arena atomically invalidates the segments, though the deallocation of the regions of memory backing the segments might not occur immediately since an expensive synchronization operation is needed to detect and cancel pending concurrent access operations on the segments.

In summary, an arena controls which threads can access a memory segment, and when, in order to provide both strong temporal safety and a predictable performance model. The FFM API offers a choice of arenas so that a client can trade off breadth of access against timeliness of deallocation.

Dereferencing segments

To dereference some data in a memory segment we need to take into account several factors:

All these characteristics are captured in the ValueLayout abstraction. For example, the predefined JAVA_INT value layout is four bytes wide, is aligned on four-byte boundaries, uses the native platform endianness (e.g., little-endian on Linux/x64), and is associated with the Java type int.

Memory segments have simple dereference methods to read values from and write values to memory segments. These methods accept a value layout, which specifies the properties of the dereference operation. For example, we can write 25 int values at consecutive offsets in a memory segment:

MemorySegment segment
    = Arena.ofAuto().allocate(100,                                   // size
                              ValueLayout.JAVA_INT.byteAlignment()); // alignment
for (int i = 0; i < 25; i++) {
    segment.setAtIndex(ValueLayout.JAVA_INT,
                       /* index */ i,
                       /* value to write */ i);
}

Memory layouts and structured access

Consider the following C declaration, which defines an array of ten Point structs, where each Point struct has two members:

struct Point {
    int x;
    int y;
} pts[10];

Using the methods shown in the previous section, we could allocate native memory for the array and initialize each of the ten Point structs with the following code (we assume that sizeof(int) == 4):

MemorySegment segment
    = Arena.ofAuto().allocate(2 * ValueLayout.JAVA_INT.byteSize() * 10, // size
                              ValueLayout.JAVA_INT.byteAlignment());    // alignment
for (int i = 0; i < 10; i++) {
    segment.setAtIndex(ValueLayout.JAVA_INT,
                       /* index */ (i * 2),
                       /* value to write */ i); // x
    segment.setAtIndex(ValueLayout.JAVA_INT,
                       /* index */ (i * 2) + 1,
                       /* value to write */ i); // y
}

To reduce the need for tedious calculations about memory layout (e.g., (i * 2) + 1 in the example above), we can use a MemoryLayout to describe the content of a memory segment in a more declarative fashion. A native memory segment that contains ten structs, each of which is a pair of ints, is described by a sequence layout that contains ten occurrences of a struct layout, each of which is a pair of JAVA_INT layouts:

SequenceLayout ptsLayout
    = MemoryLayout.sequenceLayout(10,
                                  MemoryLayout.structLayout(
                                      ValueLayout.JAVA_INT.withName("x"),
                                      ValueLayout.JAVA_INT.withName("y")));

From the sequence layout we can obtain a variable handle that can get and set a data element in any memory segment with the same layout. One kind of element that we wish to set is the member called x in an arbitrary struct in the sequence-of-structs. Accordingly, we obtain a variable handle for such elements by providing a layout path that navigates to a struct and then to its member x:

VarHandle xHandle = ptsLayout.varHandle(PathElement.sequenceElement(),
                                        PathElement.groupElement("x"));

Correspondingly, for the member y:

VarHandle yHandle = ptsLayout.varHandle(PathElement.sequenceElement(),
                                        PathElement.groupElement("y"));

We can now allocate and initialize an array of ten Point structs by allocating a native segment with the sequence-of-structs layout and then setting the two members in each successive struct via the two variable handles. Each handle accepts the MemorySegment to manipulate, the base address of the sequence-of-structs within the segment, and an index denoting which struct in the sequence-of-structs is to have its member set.

MemorySegment segment = Arena.ofAuto().allocate(ptsLayout);
for (int i = 0; i < ptsLayout.elementCount(); i++) {
    xHandle.set(segment,
                /* base */ 0L,
                /* index */ (long) i,
                /* value to write */ i); // x
    yHandle.set(segment,
                /* base */ 0L,
                /* index */ (long) i,
                /* value to write */ i); // y
}

Segment allocators

Memory allocation is often a bottleneck when clients use off-heap memory. The FFM API therefore includes a SegmentAllocator abstraction to define operations to allocate and initialize memory segments. As a convenience, the Arena class implements the SegmentAllocator interface so that arenas can be used to allocate native segments from a variety of existing sources. In other words, Arena is a "one stop shop" for flexible allocation and timely deallocation of off-heap memory:

try (Arena offHeap = Arena.ofConfined()) {
    MemorySegment nativeInt       = offHeap.allocateFrom(ValueLayout.JAVA_INT, 42);
    MemorySegment nativeIntArray  = offHeap.allocateFrom(ValueLayout.JAVA_INT,
                                                      0, 1, 2, 3, 4, 5, 6, 7, 8, 9);
    MemorySegment nativeString    = offHeap.allocateFrom("Hello!");
   ...
} // memory released here

Segment allocators can also be obtained via factories in the SegmentAllocator interface. For example, one factory creates a slicing allocator that responds to allocation requests by returning memory segments which are part of a previously allocated segment; thus, many requests can be satisfied without physically allocating more memory. The following code obtains a slicing allocator over an existing segment and then uses it to allocate a segment initialized from a Java array:

MemorySegment segment = ...
SegmentAllocator allocator = SegmentAllocator.slicingAllocator(segment);
for (int i = 0 ; i < 10 ; i++) {
    MemorySegment s = allocator.allocateFrom(ValueLayout.JAVA_INT, 1, 2, 3, 4, 5);
    ...
}

Segment allocators can be used as building blocks to create arenas that support custom allocation strategies. For example, if a large number of native segments will share the same bounded lifetime then a custom arena could use a slicing allocator to allocate the segments efficiently. This lets clients enjoy both scalable allocation (thanks to slicing) and deterministic deallocation (thanks to the arena).

As an example, the following code defines a slicing arena that behaves like a confined arena but internally uses a slicing allocator to respond to allocation requests. When the slicing arena is closed, the underlying confined arena is closed, invalidating all segments allocated in the slicing arena. (Some details are elided.)

class SlicingArena implements Arena {
     final Arena arena = Arena.ofConfined();
     final SegmentAllocator slicingAllocator;

     SlicingArena(long size) {
         slicingAllocator = SegmentAllocator.slicingAllocator(arena.allocate(size));
     }

     public void allocate(long byteSize, long byteAlignment) {
         return slicingAllocator.allocate(byteSize, byteAlignment);
    }

     public void close() {
         return arena.close();
     }
}

The earlier code which used a slicing allocator directly can now be written more succinctly:

try (Arena slicingArena = new SlicingArena(1000)) {
     for (int i = 0 ; i < 10 ; i++) {
         MemorySegment s = slicingArena.allocateFrom(ValueLayout.JAVA_INT, 1, 2, 3, 4, 5);
         ...
     }
} // all memory allocated is released here

Looking up foreign functions

The first ingredient of any support for foreign functions is a mechanism to find the address of a given symbol in a loaded native library. This capability, represented by a SymbolLookup object, is crucial for linking Java code to foreign functions (see below). The FFM API supports three different kinds of symbol lookup objects:

Given a symbol lookup object, a client can find a foreign function with the SymbolLookup::find(String) method. If the named function is present among the symbols seen by the symbol lookup then the method returns a zero-length memory segment (see below) whose base address points to the function's entry point. For example, the following code uses a loader lookup to load the OpenGL library and find the address of its glGetString function:

try (Arena arena = Arena.ofConfined()) {
    SymbolLookup opengl = SymbolLookup.libraryLookup("libGL.so", arena);
    MemorySegment glVersion = opengl.find("glGetString").get();
    ...
} // libGL.so unloaded here

SymbolLookup::libraryLookup(String, Arena) differs from JNI's library loading mechanism (i.e., System::loadLibrary) in an important way. Native libraries designed to work with JNI can use JNI functions to perform Java operations, such as object allocation or method access, which involve class loading. Therefore such libraries must be associated with a class loader when they are loaded by the JVM. Then, to preserve class loader integrity, the same JNI-using library cannot be loaded from classes defined in different class loaders.

In contrast, the FFM API does not offer functions for native code to access the Java environment, and does not assume that native libraries are designed to work with the FFM API. Native libraries loaded via SymbolLookup::libraryLookup(String, Arena) were not necessarily written to be accessed from Java code, and make no attempt to perform Java operations. As such, they are not tied to a particular class loader and can be (re)loaded as many times as needed by FFM API clients in different loaders.

Linking Java code to foreign functions

The Linker interface is the core of how Java code interoperates with native code. While in this document we often refer to interoperation between Java code and C libraries, the concepts in this interface are general enough to support other, non-Java languages in future. The Linker interface enables both downcalls (calls from Java code to native code) and upcalls (calls from native code back to Java code).

interface Linker {
    MethodHandle downcallHandle(MemorySegment address,
                                FunctionDescriptor function);
    MemorySegment upcallStub(MethodHandle target,
                          FunctionDescriptor function,
                          Arena arena);
}

For downcalls, the downcallHandle method takes the address of a foreign function — typically, a MemorySegment obtained from a library lookup — and exposes the foreign function as a downcall method handle. Later, Java code invokes the downcall method handle by calling its invoke (or invokeExact) method, and the foreign function runs. Any arguments passed to the method handle's invoke method are passed on to the foreign function.

For upcalls, the upcallStub method takes a method handle — typically, one which refers to a Java method, rather than a downcall method handle — and converts it to a MemorySegment instance. Later, the memory segment is passed as an argument when Java code invokes a downcall method handle. In effect, the memory segment serves as a function pointer. (For more information on upcalls, see below.)

Clients link to C functions using the native linker, which they obtain via Linker::nativeLinker(). The native linker is an implementation of the Linker interface that conforms to the Application Binary Interface (ABI) of the native platform on which the JVM is running. The ABI specifies the calling convention that enables code written in one language to pass arguments to code written in another language and receive a result. The ABI also specifies the size, alignment, and endianness of scalar C types, how variadic calls should be handled, and other details. While the Linker interface is neutral with respect to calling conventions, the native linker is optimized for the calling conventions of many platforms:

The native linker supports the calling conventions of other platforms by delegating to libffi.

As an example, suppose we wish to downcall from Java code to the strlen function defined in the standard C library:

size_t strlen(const char *s);

A downcall method handle that exposes strlen is obtained as follows (the details of FunctionDescriptor will be described shortly):

Linker linker = Linker.nativeLinker();
MethodHandle strlen = linker.downcallHandle(
    linker.defaultLookup().find("strlen").get(),
    FunctionDescriptor.of(JAVA_LONG, ADDRESS)
);

Invoking the downcall method handle will run strlen and make its result available to Java code. For the argument to strlen we use a helper method to convert a Java string into an off-heap memory segment, using a confined arena, which is then passed by reference:

try (Arena arena = Arena.ofConfined()) {
    MemorySegment str = arena.allocateFrom("Hello");
    long len          = (long) strlen.invoke(str);    // 5
}

Method handles work well for exposing foreign functions because the JVM already optimizes the invocation of method handles all the way down to native code. When a method handle refers to a method in a class file, invoking the method handle typically causes the target method to be JIT-compiled; subsequently, the JVM interprets the Java bytecode that calls MethodHandle::invokeExact by transferring control to the assembly code generated for the target method. Thus, a traditional method handle in Java targets non-Java code behind the scenes; a downcall method handle is a natural extension that lets developers target non-Java code explicitly. Method handles also enjoy a property called signature polymorphism which allows box-free invocation with primitive arguments. In sum, method handles let the Linker expose foreign functions in a natural, efficient, and extensible manner.

Describing C types in Java code

To create a downcall method handle, the native linker requires the client to provide a FunctionDescriptor that describes the C parameter types and C return type of the target C function. C types are described by MemoryLayout objects, principally ValueLayout, for scalar C types such as int and float, and StructLayout, for C struct types. The memory layout associated with a C struct type must be a composite layout which defines the sub-layouts for all the fields in the C struct, including any platform-dependent padding a native compiler might insert.

The native linker uses the FunctionDescriptor to derive the type of the downcall method handle. Every method handle is strongly typed, which means it is stringent about the number and types of the arguments that can be passed to its invokeExact method at run time. For example, a method handle created to take one MemorySegment argument cannot be invoked via invokeExact(<MemorySegment>, <MemorySegment>), even though invokeExact is a varargs method. The type of the downcall method handle describes the Java signature which clients must use when invoking the downcall method handle. It is, effectively, the Java-level view of the C function.

Clients must be aware of the current native platform if they target C functions that use scalar types such as long, int, and size_t. This is because the association of scalar C types with predefined value layouts varies by platform. The current platform's association between scalar C types and JAVA_* value layouts is exposed by Linker::canonicalLayouts().

As an example, suppose a downcall method handle should expose a C function that takes a C int and returns a C long:

Clients can target C functions that use pointers without being aware of the current native platform or the size of pointers on the current platform. On all platforms, a C pointer type is associated with the predefined layout ADDRESS, whose size is determined at run time. Clients do not need to distinguish between C pointer types such as int* and char**.

As an example, suppose a downcall method handle should expose a void C function that takes a pointer. Since every C pointer type is associated with the layout ADDRESS, the required FunctionDescriptor can be obtained with FunctionDescriptor.ofVoid(ADDRESS). The native linker will then arrange for the type of the downcall method handle to be the Java signature MemorySegment to void. When a MemorySegment is passed to the downcall method handle, the base address of the segment will be passed to the target C function.

Finally, unlike JNI, the native linker supports passing structured data to foreign functions. Suppose a downcall method handle should expose a void C function that takes a struct described by this layout:

MemoryLayout SYSTEMTIME  = MemoryLayout.ofStruct(
  JAVA_SHORT.withName("wYear"),      JAVA_SHORT.withName("wMonth"),
  JAVA_SHORT.withName("wDayOfWeek"), JAVA_SHORT.withName("wDay"),
  JAVA_SHORT.withName("wHour"),      JAVA_SHORT.withName("wMinute"),
  JAVA_SHORT.withName("wSecond"),    JAVA_SHORT.withName("wMilliseconds")
);

The required FunctionDescriptor can be obtained with FunctionDescriptor.ofVoid(SYSTEMTIME). The native linker will arrange for the type of the downcall method handle to be the Java signature MemorySegment to void.

Given the calling convention of the native platform, the native linker uses the FunctionDescriptor to determine how the struct's fields should be passed to the C function when a downcall method handle is invoked with a MemorySegment argument. For one calling convention, the native linker could arrange to decompose the incoming memory segment, pass the first four fields using general CPU registers, and pass the remaining fields on the C stack. For another calling convention, the native linker could arrange to pass the struct indirectly by allocating a region of memory, bulk-copying the contents of the incoming memory segment into that region, and passing a pointer to that region to the C function. This low level packaging of arguments happens behind the scenes, without any supervision by client code.

If a C function returns a by-value struct (not shown here) then a fresh memory segment must be allocated off-heap and returned to the Java client. To achieve this, the method handle returned by downcallHandle requires an additional SegmentAllocator argument which the native linker uses to allocate a memory segment to hold the struct returned by the C function.

As mentioned earlier, while the native linker is focused on providing interoperation between Java code and C libraries, the Linker interface is language-neutral: It does not specify how any native data types are defined, so clients are responsible for obtaining suitable layout definitions for C types. This choice is deliberate, since layout definitions for C types — whether simple scalars or complex structs — are ultimately platform-dependent. We expect that in practice such layouts will be mechanically generated by tools that are specific to target native platforms.

Zero-length memory segments

Foreign functions often allocate a region of memory and return a pointer to that region. Modeling such a region with a memory segment is challenging because the region's size is not available to the Java runtime. For example, a C function with return type char* might return a pointer to a region containing a single char value or to a region containing a sequence of char values terminated by '\0'. The size of the region is not readily apparent to the code calling the foreign function.

The FFM API represents a pointer returned from a foreign function as a zero-length memory segment. The address of the segment is the value of the pointer, and the size of the segment is zero. Similarly, when a client reads a pointer from a memory segment then a zero-length memory segment is returned.

A zero-length segment has trivial spatial bounds, so any attempt to access such a segment fails with IndexOutOfBoundsException. This is a crucial safety feature: Since these segments are associated with a region of memory whose size is not known, access operations involving these segments cannot be validated. In effect, a zero-length memory segment wraps an address, and it cannot be used without explicit intent.

Clients can turn a zero-length memory segment into a native segment of a specific size via the method MemorySegment::reinterpret. This method attaches fresh spatial and temporal bounds to a zero-length memory segment in order to allow dereference operations. The memory segment returned by this method is unsafe: A zero-length memory segment might be backed by a region of memory that is 10 bytes long, but the client might overestimate the size of the region and use MemorySegment::reinterpret to obtain a segment that is 100 bytes long. Later, this might result in attempts to dereference memory outside the bounds of the region, which might cause a JVM crash or — even worse — result in silent memory corruption.

Because overriding the spatial and temporal bounds of a zero-length memory segment is unsafe, the MemorySegment::reinterpret method is restricted. Using it in a program causes the Java runtime to, by default, issue warnings (see more below).

Upcalls

Sometimes it is useful to pass Java code as a function pointer to some foreign function. We can do that by using the Linker support for upcalls. In this section we build, piece by piece, a more sophisticated example which demonstrates the full power of the Linker, with full bidirectional interoperation of both code and data across the Java/native boundary.

Consider this function defined in the standard C library:

void qsort(void *base, size_t nmemb, size_t size,
           int (*compar)(const void *, const void *));

To call qsort from Java code, we first need to create a downcall method handle:

Linker linker = Linker.nativeLinker();
MethodHandle qsort = linker.downcallHandle(
    linker.defaultLookup().find("qsort").get(),
    FunctionDescriptor.ofVoid(ADDRESS, JAVA_LONG, JAVA_LONG, ADDRESS)
);

As before, we use the JAVA_LONG layout to map the C size_t type, and we use the ADDRESS layout for both the first pointer parameter (the array pointer) and the last parameter (the function pointer).

qsort sorts the contents of an array using a custom comparator function, compar, passed as a function pointer. Therefore, to invoke the downcall method handle we need a function pointer to pass as the last parameter to the method handle's invokeExact method. Linker::upcallStub helps us create function pointers by using existing method handles, as follows.

First, we write a static method that compares two int values, represented indirectly as MemorySegment objects:

class Qsort {
    static int qsortCompare(MemorySegment elem1, MemorySegment elem2) {
        return Integer.compare(elem1.get(JAVA_INT, 0), elem2.get(JAVA_INT, 0));
    }
}

Second, we create a method handle pointing to the Java comparator method:

MethodHandle comparHandle
    = MethodHandles.lookup()
                   .findStatic(Qsort.class, "qsortCompare",
                               MethodType.methodType(int.class,
                                                     MemorySegment.class,
                                                     MemorySegment.class));

Third, now that we have a method handle for our Java comparator we can create a function pointer using Linker::upcallStub. Just as for downcalls, we describe the signature of the function pointer using a FunctionDescriptor:

MemorySegment comparFunc
    = linker.upcallStub(comparHandle,
                        /* A Java description of a C function
                           implemented by a Java method! */
                        FunctionDescriptor.of(JAVA_INT,
                                              ADDRESS.withTargetLayout(JAVA_INT),
                                              ADDRESS.withTargetLayout(JAVA_INT)),
                        Arena.ofAuto());

We finally have a memory segment, comparFunc, which points to a stub that can be used to invoke our Java comparator function, and so we now have all we need to invoke the qsort downcall handle:

try (Arena arena = Arena.ofConfined()) {
    MemorySegment array
        = arena.allocateFrom(ValueLayout.JAVA_INT,
                             0, 9, 3, 4, 6, 5, 1, 8, 2, 7);
    qsort.invoke(array, 10L, ValueLayout.JAVA_INT.byteSize(), comparFunc);
    int[] sorted = array.toArray(JAVA_INT);    // [ 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 ]
}

This code creates an off-heap array, copies the contents of a Java array into it, and then passes the array to the qsort handle along with the comparator function we obtained from the native linker. After the invocation, the contents of the off-heap array will be sorted according to our comparator function, written as Java code. We then extract a new Java array from the segment, which contains the sorted elements.

Safety

Fundamentally, any interaction between Java code and native code can compromise the integrity of the Java Platform. Linking to a C function in a precompiled library is inherently unreliable because the Java runtime cannot guarantee that the function's signature matches the expectations of the Java code, or even that a symbol in a C library really denotes a function. Moreover, even if a suitable function is linked, actually calling the function can lead to low-level failures, such as segmentation faults, that end up crashing the VM. Such failures cannot be prevented by the Java runtime or caught by Java code.

Native code that uses JNI functions is especially dangerous. Such code can access JDK internals, without command-line flags (e.g., --add-opens), by using JNI functions such as GetFieldID and SetObjectField. It can also change the values of final fields long after they are initialized. Allowing native code to bypass the checks applied to Java code undermines every boundary and assumption in the JDK. In other words, JNI is inherently unsafe.

JNI cannot be disabled, so there is no way to ensure that Java code will not call native code which uses dangerous JNI functions. This is a risk to platform integrity that is almost invisible to application developers and end users because 99% of the use of these functions is typically from third, fourth, and fifth-party libraries sandwiched between the application and the JDK.

Most of the FFM API is safe by design. Many scenarios that required the use of JNI and native code in the past can be accomplished by calling methods in the FFM API, which cannot compromise the Java Platform. For example, a primary use case for JNI, flexible memory allocation, is supported with a simple method, MemorySegment::allocateNative, that involves no native code and always returns memory managed by the Java runtime. Generally speaking, Java code that uses the FFM API cannot crash the JVM.

Part of the FFM API, however, is inherently unsafe. When interacting with the Linker, Java code can request a downcall method handle by specifying parameter types that are incompatible with those of the underlying foreign function. Invoking that method handle code will result in the same kind of outcome — a VM crash, or undefined behavior — that can occur when invoking a native method in JNI. The FFM API can also produce unsafe segments, that is, memory segments whose spatial and temporal bounds are user-provided and cannot be verified by the Java runtime (see MemorySegment::reinterpret).

The unsafe methods in the FFM API do not pose the same risks as JNI functions. They cannot, e.g., change the values of final fields in Java objects. On the other hand, the unsafe methods in the FFM API are easy to call from Java code. For this reason, the use of unsafe methods in the FFM API is restricted: Their use is permitted but, by default, every such use causes a warning to be issued at run time.

To allow code in a module M to use unsafe methods without warnings, specify the --enable-native-access=M option on the java command line. Specify multiple modules with a comma-separated list; specify ALL-UNNAMED to enable warning-free use for all code on the class path. In addition, the JAR-file manifest attribute Enable-Native-Access: ALL-UNNAMED can be used in an executable JAR to enable warning-free use for all code on the class path; no other module name can be given as the value of the attribute.

When the --enable-native-access option is present, any use of unsafe methods from outside the list of specified modules will cause an IllegalCallerException to be thrown, rather than a warning to be issued. In a future release, it is likely that this option will be required in order to use unsafe methods — that is, if the option is not present, their use will cause not a warning but rather an IllegalCallerException.

We do not propose here to restrict any aspect of JNI. It will still be possible to call native methods in Java, and for native code to call unsafe JNI functions. However, it is likely that we will restrict JNI in some way in a future release. For example, unsafe JNI functions such as NewDirectByteBuffer can be disabled by default, just like unsafe methods in the FFM API. More broadly, the JNI mechanism is so irredeemably dangerous that we hope libraries will prefer the pure-Java FFM API for both safe and unsafe operations so that, in time, we can disable all of JNI by default. This aligns with the broader Java roadmap of making the platform safe out-of-the-box, requiring end users to opt-in to unsafe activities such as breaking strong encapsulation or linking to unknown code.

We do not propose here to change sun.misc.Unsafe in any way. The FFM API's support for off-heap memory is an excellent alternative to the wrappers around malloc and free in sun.misc.Unsafe, namely allocateMemory, setMemory, copyMemory, and freeMemory. We hope that libraries and applications that require off-heap storage adopt the FFM API so that, in time, we can deprecate and then eventually remove these sun.misc.Unsafe methods.

Risks and Assumptions

Creating an API to access foreign memory in a way that is both safe and efficient is a daunting task. Since the spatial and temporal checks described in the previous sections need to be performed upon every access, it is crucial that JIT compilers be able to optimize away these checks by, e.g., hoisting them outside of hot loops. The JIT implementations will likely require some work to ensure that uses of the API are as efficient and optimizable as uses of existing APIs such as ByteBuffer and Unsafe. The JIT implementations will also require work to ensure that uses of the native method handles retrieved from the API are at least as efficient and optimizable as uses of existing JNI native methods.

Dependencies