MYRA stack - modern JAVA FFM based libraries

2025-11-29T00:00:00+00:00

Introducing MYRA: What I’ve Been Building</h1>

Overview</h2>
MYRA — Memory Yielded, Rapid Access — is a production-grade ecosystem of Java libraries built on the Foreign Function & Memory (FFM) API, designed for deterministic, sub-microsecond latency applications.
Unlike approaches that rely on `Unsafe</code> or JNI boilerplate, MYRA leverages the standardized FFM primitives introduced in Java 22, providing memory safety and future-proof compatibility without sacrificing performance.`

Design Principles</h3> The ecosystem is built on four core principles: Zero GC: Off-heap allocation and deterministic resource management eliminate GC pauses in the critical path.</li> Zero Allocation: Reusable object instances and flyweight patterns prevent heap churn.</li> Zero Copy: Direct memory access and structured layout eliminate serialization overhead.</li> Ultra-Low Latency: Sub-30μs mean latencies with controlled tail behavior, built for high-frequency trading, market data feeds, and real-time systems.</li> </ul> The Problem FFM Solves</h2> Performance-sensitive Java systems have historically relied on Unsafe</code> — a powerful but unstable internal API that breaks with each JDK release. The Foreign Function & Memory API provides a safe, standardized alternative for off-heap memory access and native interoperability. MYRA is built entirely on FFM, proving that it’s not just a replacement for Unsafe</code>, but a foundation for a new class of infrastructure libraries that were previously impossible to build safely on the JVM. What’s in the Box</h2> MYRA comprises six libraries designed for vertical integration: roray-ffm-utils — Memory arenas, direct buffers, native resource handling. The plumbing layer.</li> myra-codec — Zero-copy serialization that reads and writes directly to off-heap memory. No intermediate objects.</li> myra-transport — Networking built on Linux io_uring</code>. Fewer syscalls, higher throughput.</li> MVP.Express RPC — MYRA Virtual Procedure over Express Link — A lightweight RPC framework on top of the above. Currently in progress.</li> JIA-Cache — Java In-Memory Accelerated Cache — Off-heap caching with predictable latency. Coming soon.</li> </ul> The libraries share a design philosophy: zero allocation in the hot path. If you’re processing millions of messages per second, you shouldn’t be at the mercy of GC pauses. A key enabler is the flyweight pattern — reusable, stateless views over raw memory. Instead of deserializing into objects, myra-codec and myra-transport wrap off-heap buffers directly. No copies, no allocations, no GC pressure. Just pointer arithmetic and bounds checks. Use Cases & Industries</h2> MYRA is built for systems where every microsecond counts: High-Frequency Trading (HFT) — Order routing, execution, and market data pipelines where sub-10μs latency directly impacts profitability.</li> Cryptocurrency Exchanges — Real-time order books, settlement, and websocket broadcasts at millions of events per second.</li> AdTech Real-Time Bidding — Sub-millisecond ad auctions and bid evaluation at scale.</li> Market Data Distribution — Low-latency feeds for equities, derivatives, commodities, and crypto with minimal GC interference.</li> Game Engines & Networked Games — High-tick-rate game loops and multiplayer synchronization with deterministic latency.</li> Financial Risk Systems — Real-time portfolio valuation, Greeks calculation, and stress testing for trading desks.</li> Sensor Networks & IoT — Time-series ingestion and edge processing for IoT data with strict latency budgets.</li> Telecommunications — Signaling, traffic analysis, and real-time network telemetry.</li> Cybersecurity Monitoring — Real-time threat detection and packet analysis at line rate.</li> </ul> Any system processing high-volume, low-latency, deterministic workloads is a candidate for MYRA. Benchmarks: Codec</h2> Serialization is where myra-codec shines. On an order book snapshot workload (a common HFT/trading message type), here’s how it stacks up against established codecs: Decode Throughput (ops/sec) — Higher is Better ════════════════════════════════════════════════════════════════════ Myra ████████████████████████████████████████ 4,150,079 ⭐ SBE ████████████████████ 2,204,557 FlatBuffers █████████████████ 1,968,855 Kryo ███████████████ 1,322,754 Avro █████ 454,553 Encode Throughput (ops/sec) — Higher is Better ════════════════════════════════════════════════════════════════════ SBE ████████████████████████████████████████ 4,990,071 Myra ███████████████ 1,911,781 ⭐ Kryo ███████████ 1,342,611 FlatBuffers ████████ 1,045,843 Avro ████ 466,816 </code></pre> Myra decode is 2-3x faster than Kryo/FlatBuffers and leads the pack. SBE edges out Myra on encode, but Myra’s decode dominance makes it the better choice for read-heavy workloads (most real systems decode more than they encode). Codec</th> Decode (ops/s)</th> Encode (ops/s)</th> vs Myra (decode)</th> vs Myra (encode)</th></tr></thead> Myra</td> 4,150,079</td> 1,911,781</td> —</td> —</td></tr> SBE</td> 2,204,557</td> 4,990,071</td> -47%</td> +161%</td></tr> FlatBuffers</td> 1,968,855</td> 1,045,843</td> -53%</td> -45%</td></tr> Kryo</td> 1,322,754</td> 1,342,611</td> -68%</td> -30%</td></tr> Avro</td> 454,553</td> 466,816</td> -89%</td> -76%</td></tr> </tbody></table> Benchmark: order_book_snapshots workload, JMH on c6a.4xlarge, JDK 25, 5 forks × 5 iterations. Benchmarks: Transport</h2> For networking, myra-transport uses Linux io_uring</code> to bypass the traditional syscall overhead. Here’s how it compares in a ping-pong latency test with realistic payloads: Mean Latency (μs) — Lower is Better ════════════════════════════════════════════════════════════════════ NIO █████████████ 13.22 μs MYRA_TOKEN ███████████████████████ 28.70 μs ⭐ MYRA ████████████████████████████ 35.12 μs MYRA_SQPOLL █████████████████████████████ 35.88 μs Netty ███████████████████████████████ 39.34 μs Throughput (ops/sec) — Higher is Better ════════════════════════════════════════════════════════════════════ NIO ████████████████████████████████████████ 75,645 MYRA_TOKEN ██████████████████ 34,843 ⭐ MYRA ███████████████ 28,471 MYRA_SQPOLL ██████████████ 27,873 Netty █████████████ 25,417 </code></pre> MYRA_TOKEN beats Netty by 27% on latency (28.7 μs vs 39.3 μs) and 37% on throughput. The token-based completion tracking provides the best balance of latency and consistency for io_uring-based networking. Implementation</th> Mean (μs)</th> p50 (μs)</th> p99 (μs)</th> Throughput</th> vs Netty</th></tr></thead> NIO (baseline)</td> 13.22</td> 12.27</td> 28.35</td> 75.6K ops/s</td> +198%</td></tr> MYRA_TOKEN ⭐</td> 28.70</td> 26.72</td> 45.76</td> 34.8K ops/s</td> +37%</td></tr> MYRA</td> 35.12</td> 32.16</td> 53.25</td> 28.5K ops/s</td> +12%</td></tr> MYRA_SQPOLL</td> 35.88</td> 25.50</td> 63.36</td> 27.9K ops/s</td> +10%</td></tr> Netty</td> 39.34</td> 38.34</td> 62.40</td> 25.4K ops/s</td> —</td></tr> </tbody></table> Benchmark: RealWorldPayload ping-pong, JMH on ARM64 (AWS Graviton), JDK 25, Nov 29, 2025. Why Java Instead of C/C++/Rust?</h2> A common question: “If you need this kind of performance, why not just write it in C/C++/Rust?” It’s a fair question. The short answer: developer velocity, safety, and maintainability matter more than the last 5-10% of performance. The C/C++ Problem</h3> Writing correct, memory-safe high-performance C/C++ code is genuinely hard: Undefined behavior lurks everywhere. Cache line aliasing, pointer provenance violations, strict aliasing optimizations — seemingly small mistakes cause non-deterministic failures in production.</li> Memory safety requires obsessive discipline. Buffer overflows, use-after-free, double-free — these are career-ending bugs that tests often miss until they surface under load.</li> SIMD and CPU features are implicit. Vectorization depends on compiler whim. Portability across architectures (x86 → ARM → POWER) requires conditional code paths and platform-specific profiling.</li> Latency is still unpredictable. Memory allocators, cache eviction, TLB misses, branch misprediction — none are under your control. You optimize by convention and prayer.</li> Recruitment is painful. Finding developers who can write safe, correct C++ at scale is expensive. Most teams end up with a small cadre of specialists maintaining critical paths.</li> </ul> The Rust Problem</h3> Rust solves memory safety, but introduces different tradeoffs: The learning curve is steep. Ownership semantics, borrow checking, lifetime parameters — experienced C++ developers typically need several months to become productive. Most teams don’t have that timeline.</li> Async ecosystem fragmentation. Tokio, async-std, embassy — Rust has no single async standard. A 5-year-old codebase may be stuck on an abandoned runtime.</li> Talent pool is shallow. Rust adoption in production is still niche. Hiring is hard, and most candidates come from crypto/systems backgrounds, not mainstream finance.</li> Performance isn’t guaranteed. Zero-cost abstractions are a design goal, not a promise. Allocations, copies, and data layout still require deep expertise to optimize.</li> Build times are brutal. Incremental compilation is improving, but debug builds still feel glacial compared to JVM languages.</li> </ul> Why Java/FFM Changes the Equation</h3> The MYRA stack bridges the gap: Memory safety by default. FFM operates within JVM bounds checking. No segfaults, no undefined behavior. You still get off-heap access and native interop, but with guardrails.</li> Deterministic behavior. The JVM’s memory model is formal and well-defined. No undefined behavior. No surprise optimizations that break correctness.</li> GC is optional. With MYRA’s zero-allocation design, you can run on low-pause GCs (ZGC, Shenandoah) or even custom pauseless allocators. You’re not forced into stop-the-world pauses.</li> Massive ecosystem. Maven, Spring, Quarkus, Loom — the JVM has 25+ years of production infrastructure. No reinventing logging, serialization, or concurrency primitives.</li> Tooling maturity. JVM profilers (async-profiler, Flight Recorder), debuggers, and observability are industry-standard. Compare to gdb + perf or valgrind’s UI.</li> Developer velocity is real. Java developers are abundant. They can become productive with MYRA in weeks, not months. Bugs in business logic surface faster than memory corruption.</li> Performance is competitive. At 13-28μs ping-pong latency, MYRA is in the same ballpark as hand-optimized C++. Not 2x faster, but also not 2x slower. The 10-15% gap is often worth the 10x faster time-to-market.</li> </ul> The Reality Check</h3> C/C++/Rust shine for: Embedded systems where memory is scarce (ARM Cortex M, RISC-V).</li> Bare-metal or kernel-mode code where a JVM isn’t an option.</li> Latency-critical at scale — when you’re processing trillions of messages/year and 1μs matters.</li> </ul> But for most systems — trading platforms, market data feeds, game servers, real-time analytics — Java + MYRA offers a pragmatic middle ground: Close to C++ performance without the memory safety tax.</li> Safer and faster to develop than Rust, with a deeper talent pool.</li> Proven production stability with 25+ years of JVM track record.</li> </ul> MYRA’s thesis is simple: Most teams are over-optimized for raw speed and under-optimized for correctness and velocity. The JVM with FFM tips that balance back toward sanity. Why I’m Building This</h2> I’ve spent years in systems where latency matters — where 100μs is slow and a GC pause is a production incident. Java is plenty fast for this, but the tooling hasn’t caught up to the platform’s capabilities. FFM is the missing piece. It’s finally safe, stable, and performant enough to build real infrastructure on. MYRA is my attempt to do exactly that. What’s Next</h2> I’m currently in the final stretch — optimizations, cleanup, and documentation. The goal is to publicly open source the entire ecosystem by Christmas 2025. The MYRA ecosystem will always remain free and open source. No enterprise tier, no gated features, no open-core model. Development will be sustained through open sponsorships from individuals and organizations who find value in the work. If you’re curious about FFM, high-performance Java, or just want to see where this goes: Follow the project: github.com/mvp-express</a> More soon. Java FFM - Foreign Function & Memory Access API (Project Panama) 2025-08-28T00:00:00+00:00 TL;DR</h1> Java’s Foreign Function & Memory (FFM) API enables safe, high-performance interaction with native code and memory, improving interoperability with other languages and access to low-level system resources. Entire source code available on GitHub</a>. Overview</h1> The Foreign Function & Memory (FFM) API in Java, finalized in JDK 22 with JEP 454, provides a robust and safe mechanism for Java code to interact with foreign functions (native code) and foreign memory (memory outside the Java heap). The FFM API is designed to be a safer, more efficient, and more user-friendly alternative to the Java Native Interface (JNI). JNI is known for its complexity and potential for introducing errors, whereas FFM aims to provide a more "Java-first" programming model for native interoperability. The FFM API introduces several key concepts and components that facilitate foreign function and memory access in Java: Memory Segments: A memory segment is a contiguous block of memory that can be accessed by Java programs. The FFM API provides a way to create and manage memory segments, allowing developers to allocate and deallocate memory as needed. </li> Arena Allocation: The FFM API introduces the concept of arenas, which are memory pools that can be used for efficient allocation and deallocation of memory. Arenas help reduce fragmentation and improve performance when working with native memory. </li> Value Layouts: Value layouts define the memory layout of data structures in a platform-independent way. The FFM API allows developers to create value layouts for both Java and foreign types, ensuring compatibility between the two. </li> Memory Access: The FFM API provides a set of APIs for reading and writing data to memory segments, making it easy to manipulate native data from Java. </li> Foreign Functions: Foreign functions are native functions written in languages like C or C++ that can be called from Java. The FFM API provides a way to define and invoke foreign functions, enabling seamless integration between Java and native code. </li> </ol> Note: While the primary use case of the Java Foreign Function & Memory (FFM) API is to call C functions from Java (downcalls), it also supports the reverse: calling Java functions from C (upcalls). This is particularly useful for scenarios like C callbacks, where a C library needs to invoke a function provided by Java code. </blockquote> FFM Use cases</h1> By leveraging these components, developers can build high-performance applications that take advantage of native libraries and system resources while maintaining the safety and ease of use that Java provides especially in below use cases: Performance-Critical Applications: Applications that require high performance such as game engines, scientific computing, Ultra Low Level (ULL) High Frequency Trading (HFT) systems and real-time systems can benefit from direct access to native code and memory.</li> Big Data and Machine Learning: Libraries like TensorFlow and PyTorch often require efficient memory management and native code execution, making FFM a suitable choice for integrating these libraries into Java applications.</li> Interoperability with Other Languages: FFM allows Java applications to easily call functions written in other languages, such as C or C++, enabling developers to leverage existing libraries and codebases</li> Low-Level System Access: Applications that need to interact with low-level system resources, such as hardware devices or operating system APIs, can use FFM to access these resources directly from Java e.g. accessing NIC for Kernel bypass networking, accessing GPU for parallel processing, etc.</li> High Performance Computing (HPC): FFM can be used in HPC applications where performance is critical, such as simulations, numerical computations, and data processing tasks that require efficient memory management and native code execution.</li> High Performance File/Data I/O: Database files, large binary files, and other data-intensive applications can benefit by using techniques like memory-mapped files which allow direct access to file contents in memory, random access, bulk read, minimize OS calls, Zero copy & low GC pressure by avoiding Heap, multi-process file coordination with locks improving I/O performance and reducing latency.</li> Custom High Performance Low Latency RPC: Remote Procedure Calls (RPC) can be optimized using FFM to reduce serialization/deserialization overhead, enabling faster communication with high throughput between distributed systems.</li> </ul> Demo Example</h1> Let’s see a small example of effective usage of FFM. As a Proof of Concept, we will create a TCP server using io_uring</a> (Linux kernel interface for asynchronous I/O operations) and Java FFM API. The actual TCP server using io_uring is implemented in C. We will use various APIs (standard TCP operations) viz. accept, listen, connect, send, receive etc. in Java through Foreign Functions mapping the actual C functions. This is by no means a production ready code. The goal is to showcase the ease of use and integration of FFM with existing C libraries. We also won’t be going into details of TCP server implementation in C nor what is io_uring as it’s beyond the scope of this article. TCP server in C using async io-uring</h2> Let’s look at the C code</a> first especially the below APIs: io_uring_global_init</code> - Initializes the global io_uring context and sets up the underlying ring buffers for asynchronous I/O operations</li> io_uring_listen</code> - Creates a TCP socket, binds it to a specified port, and starts listening for incoming connections</li> io_uring_accept</code> - Accepts an incoming connection request and returns a new socket file descriptor for the client</li> io_uring_connect</code> - Establishes an outbound TCP connection to a remote server at the specified address and port</li> io_uring_send</code> - Sends data through an established TCP connection using io_uring’s asynchronous write operations</li> io_uring_receive</code> - Receives data from an established TCP connection using io_uring’s asynchronous read operations</li> </ul> Java - FFM Integration</h2> Now let’s look at the Java side which is the point of interest of this article. We have 2 classes: FfmReceiver</code> - Responsible for receiving data from the TCP server</li> FfmSender</code> - Responsible for sending data to the TCP server</li> </ul> Note: The actual TCP server is implemented in C using io_uring. The C library exposes lifecycle methods for managing the server. These methods are then called in Java using FFM. FfmReceiver</h3> 1</td> import java.lang.foreign.Arena; </td></tr> 2</td> import java.lang.foreign.FunctionDescriptor; </td></tr> 3</td> import java.lang.foreign.Linker; </td></tr> 4</td> import java.lang.foreign.MemorySegment; </td></tr> 5</td> import java.lang.foreign.SymbolLookup; </td></tr> 6</td> import java.lang.foreign.ValueLayout; </td></tr> 7</td> import java.lang.invoke.MethodHandle; </td></tr> 8</td> import java.nio.charset.StandardCharsets; </td></tr> 9</td> </td></tr> 10</td> public class FfmReceiver { </td></tr> 11</td> </td></tr> 12</td> private static final ValueLayout.OfByte BYTE = ValueLayout.Java_BYTE; </td></tr> 13</td> </td></tr> 14</td> public static void main(String[] args) throws Throwable { </td></tr> 15</td> int queueDepth = 32; </td></tr> 16</td> int port = 22345; </td></tr> 17</td> int backlog = 128; </td></tr> 18</td> long bufferSize = 8 * 1024 * 1024; // 8 MB buffer per client </td></tr> 19</td> </td></tr> 20</td> try (Arena arena = Arena.ofShared()) { </td></tr> 21</td> </td></tr> 22</td> // Load the shared library </td></tr> 23</td> SymbolLookup lib = SymbolLookup.libraryLookup("./libiouring_tcp.so", arena); </td></tr> 24</td> Linker linker = Linker.nativeLinker(); </td></tr> 25</td> </td></tr> 26</td> // 1️⃣ Global Init </td></tr> 27</td> MemorySegment globalInitAddr = lib.find("io_uring_global_init").get(); </td></tr> 28</td> MethodHandle mhGlobalInit = linker.downcallHandle(globalInitAddr, </td></tr> 29</td> FunctionDescriptor.of(ValueLayout.Java_INT, ValueLayout.Java_INT)); </td></tr> 30</td> int ret = (int) mhGlobalInit.invokeExact(queueDepth); </td></tr> 31</td> System.out.println("io_uring_global_init returned: " + ret); </td></tr> 32</td> </td></tr> 33</td> // 2️⃣ Listen (server socket) </td></tr> 34</td> MemorySegment listenAddr = lib.find("io_uring_listen").get(); </td></tr> 35</td> MethodHandle mhListen = linker.downcallHandle(listenAddr, </td></tr> 36</td> FunctionDescriptor.of(ValueLayout.Java_INT, ValueLayout.Java_INT, ValueLayout.Java_INT)); </td></tr> 37</td> int listenFd = (int) mhListen.invokeExact(port, backlog); </td></tr> 38</td> if (listenFd < 0) { </td></tr> 39</td> throw new RuntimeException("io_uring_listen failed, fd=" + listenFd); </td></tr> 40</td> } </td></tr> 41</td> System.out.println("Server listening on port " + port + ", fd=" + listenFd); </td></tr> 42</td> </td></tr> 43</td> // 3️⃣ Accept clients in a loop </td></tr> 44</td> MemorySegment acceptAddr = lib.find("io_uring_accept").get(); </td></tr> 45</td> MethodHandle mhAccept = linker.downcallHandle(acceptAddr, </td></tr> 46</td> FunctionDescriptor.of(ValueLayout.Java_INT, ValueLayout.Java_INT)); </td></tr> 47</td> </td></tr> 48</td> MemorySegment recvAddr = lib.find("io_uring_recv").get(); </td></tr> 49</td> MethodHandle mhRecv = linker.downcallHandle(recvAddr, </td></tr> 50</td> FunctionDescriptor.of(ValueLayout.Java_INT, ValueLayout.Java_INT, ValueLayout.ADDRESS, ValueLayout.Java_LONG)); </td></tr> 51</td> </td></tr> 52</td> while (true) { </td></tr> 53</td> int clientFd = (int) mhAccept.invokeExact(listenFd); </td></tr> 54</td> if (clientFd < 0) { </td></tr> 55</td> System.err.println("Accept failed, fd=" + clientFd); </td></tr> 56</td> continue; </td></tr> 57</td> } </td></tr> 58</td> System.out.println("Client connected, fd=" + clientFd); </td></tr> 59</td> </td></tr> 60</td> // Allocate buffer for this client </td></tr> 61</td> MemorySegment buffer = arena.allocate(bufferSize); </td></tr> 62</td> </td></tr> 63</td> int bytesReceived = (int) mhRecv.invokeExact(clientFd, buffer, bufferSize); </td></tr> 64</td> if (bytesReceived < 0) { </td></tr> 65</td> System.err.println("io_uring_recv failed, bytes=" + bytesReceived); </td></tr> 66</td> continue; </td></tr> 67</td> } </td></tr> 68</td> System.out.println("Received bytes: " + bytesReceived); </td></tr> 69</td> </td></tr> 70</td> // Print first 128 bytes for debugging (optional) </td></tr> 71</td> int displayLen = Math.min(128, bytesReceived); </td></tr> 72</td> byte[] arr = new byte[displayLen]; </td></tr> 73</td> for (int i = 0; i < displayLen; i++) { </td></tr> 74</td> arr[i] = buffer.get(BYTE, i); </td></tr> 75</td> } </td></tr> 76</td> System.out.println("First " + displayLen + " bytes:\n" + </td></tr> 77</td> new String(arr, StandardCharsets.US_ASCII)); </td></tr> 78</td> </td></tr> 79</td> // Close client socket </td></tr> 80</td> MemorySegment closeAddr = lib.find("io_uring_close").get(); </td></tr> 81</td> MethodHandle mhClose = linker.downcallHandle(closeAddr, </td></tr> 82</td> FunctionDescriptor.ofVoid(ValueLayout.Java_INT)); </td></tr> 83</td> mhClose.invokeExact(clientFd); </td></tr> 84</td> System.out.println("Client fd " + clientFd + " closed."); </td></tr> 85</td> } </td></tr> 86</td> </td></tr> 87</td> // 4️⃣ Optional: shutdown ring (never reached in infinite loop) </td></tr> 88</td> // MemorySegment shutdownAddr = lib.find("io_uring_global_shutdown").get(); </td></tr> 89</td> // MethodHandle mhShutdown = linker.downcallHandle(shutdownAddr, FunctionDescriptor.ofVoid()); </td></tr> 90</td> // mhShutdown.invokeExact(); </td></tr> 91</td> } </td></tr> 92</td> } </td></tr> 93</td> } </td></tr></tbody></table></code></pre> This FfmReceiver class demonstrates a complete FFM workflow for calling native C functions from Java. Here’s the high-level technical breakdown: Library Loading & Symbol Resolution FFM loads the compiled C shared library containing io_uring functions. SymbolLookup provides a bridge to find C function symbols by name. Key FFM Components in Action Arena: Manages native memory lifecycle - automatically frees all allocated memory when closed (safe malloc/free).</li> SymbolLookup: This is how Java finds function pointers in a native library. Think of SymbolLookup as a “directory of functions” inside the .so file.</li> Linker: The bridge between Java and native code, which knows how to convert between Java calling conventions and the platform’s native ABI (x86_64 Linux, ARM64, etc.).</li> FunctionDescriptor: Defines the C/native function signature (return type + parameter types)</li> ValueLayout: Maps Java types to native types (Java_INT → C int, ADDRESS → C pointer)</li> MethodHandle: Type-safe wrapper for C/native function calls</li> MemorySegment: Represents native memory buffers for data exchange; essentially a safe pointer with guardrails.</li> </ul> Memory Management Native memory is allocated outside the Java heap. Data is directly read/written to native buffers without copying (zero copy). Arena ensures safe & automatic cleanup when the try-with-resources block exits. Here, arena is used both to load the library and allocate buffers for receiving data. Here, libraryLookup loads our custom shared library (.so) and lets us find symbols like io_uring_global_init, io_uring_listen, etc. Then with linker, we can create MethodHandles that behave like normal Java methods but actually invoke C functions. We can think of a MethodHandle as a Java wrapper around a native C function. A linker can be thought of as a translator between Java’s JVM world and C’s native/binary code. Next, we define the function signature with FunctionDescriptor.of(Java_INT, Java_INT) which includes parameter(input) types & all return types. In this case, the function says it takes one int argument & returns one int as the result. invokeExact(queueDepth) → actually executes the C function. Safety & Type Checking invokeExact() enforces exact type matching between Java and C function signatures. Compile-time validation prevents type mismatches that would cause runtime errors. No manual memory management or pointer arithmetic required. This approach eliminates JNI’s complexity while providing direct, high-performance access to native libraries with Java’s safety guarantees intact. Click here</a> to see a more detailed AI generated walk through of FfmReceiver implementation. Sample Output: FfmSender</h3> 1</td> import java.lang.foreign.*; </td></tr> 2</td> import java.lang.invoke.MethodHandle; </td></tr> 3</td> import java.nio.charset.StandardCharsets; </td></tr> 4</td> </td></tr> 5</td> public class FfmSender { </td></tr> 6</td> public static void main(String[] args) throws Throwable { </td></tr> 7</td> int queueDepth = 32; </td></tr> 8</td> int port = 22345; </td></tr> 9</td> long bufferSize = 4 * 1024; // 4 KB buffer per client </td></tr> 10</td> </td></tr> 11</td> System.out.println("FfmSender running..."); </td></tr> 12</td> try (Arena arena = Arena.ofShared()) { </td></tr> 13</td> String hi = "ping"; </td></tr> 14</td> </td></tr> 15</td> // Load the shared library </td></tr> 16</td> SymbolLookup lib = SymbolLookup.libraryLookup("./libiouring_tcp.so", arena); </td></tr> 17</td> Linker linker = Linker.nativeLinker(); </td></tr> 18</td> </td></tr> 19</td> // Global IO URing Init </td></tr> 20</td> MemorySegment globalInitAddrMS = lib.find("io_uring_global_init").get(); </td></tr> 21</td> FunctionDescriptor globalInitFD = FunctionDescriptor.of( </td></tr> 22</td> ValueLayout.Java_INT, </td></tr> 23</td> ValueLayout.Java_INT); </td></tr> 24</td> MethodHandle globalInitMH = linker.downcallHandle(globalInitAddrMS, globalInitFD); </td></tr> 25</td> int ret = (int) globalInitMH.invokeExact(queueDepth); </td></tr> 26</td> System.out.println("io_uring_global_init returned: " + ret); </td></tr> 27</td> </td></tr> 28</td> // TCP Open Socket FD </td></tr> 29</td> MemorySegment tcpSocketAddrMS = lib.find("io_uring_connect").get(); </td></tr> 30</td> FunctionDescriptor tcpConnectFD = FunctionDescriptor.of( </td></tr> 31</td> ValueLayout.Java_INT, // return value of socket File Descriptor </td></tr> 32</td> ValueLayout.ADDRESS, // server address </td></tr> 33</td> ValueLayout.Java_INT); // server port </td></tr> 34</td> MethodHandle tcpConnectMH = linker.downcallHandle(tcpSocketAddrMS, tcpConnectFD); </td></tr> 35</td> </td></tr> 36</td> String ip = "127.0.0.1"; // destination IP </td></tr> 37</td> byte[] ipBytes = ip.getBytes(StandardCharsets.UTF_8); </td></tr> 38</td> MemorySegment ipStr = arena.allocate(ipBytes.length + 1); </td></tr> 39</td> ipStr.asSlice(0, ipBytes.length).copyFrom(MemorySegment.ofArray(ipBytes)); </td></tr> 40</td> ipStr.set(ValueLayout.Java_BYTE, ipBytes.length, (byte) 0); // Null-terminate for C </td></tr> 41</td> </td></tr> 42</td> int socketFD = (int) tcpConnectMH.invokeExact(ipStr, port); </td></tr> 43</td> </td></tr> 44</td> // IO URing send data through memory segment off-heap buffer </td></tr> 45</td> MemorySegment sendBufAddrMS = lib.find("io_uring_send_all").get(); </td></tr> 46</td> FunctionDescriptor sendBufFD = FunctionDescriptor.of( </td></tr> 47</td> ValueLayout.Java_INT, // return value: total sent bytes </td></tr> 48</td> ValueLayout.Java_INT, // socket fd </td></tr> 49</td> ValueLayout.ADDRESS, // buffer address </td></tr> 50</td> ValueLayout.Java_LONG); // buffer length </td></tr> 51</td> MethodHandle sendBufMH = linker.downcallHandle(sendBufAddrMS, sendBufFD); </td></tr> 52</td> </td></tr> 53</td> // Prepare buffer </td></tr> 54</td> MemorySegment sendBuf = arena.allocateFrom(hi); </td></tr> 55</td> </td></tr> 56</td> int totalBytesSent = (int) sendBufMH.invokeExact(socketFD, sendBuf, (long) hi.length()); </td></tr> 57</td> </td></tr> 58</td> System.out.println("Total bytes sent Java FFM: " + totalBytesSent); </td></tr> 59</td> </td></tr> 60</td> } </td></tr> 61</td> </td></tr> 62</td> } </td></tr> 63</td> } </td></tr></tbody></table></code></pre> Sample Output: This FfmSender class demonstrates sending data to the TCP server using FFM. The flow is similar to FfmReceiver. We send “ping” text to the TCP Server > FfmReceiver. Appendix</h1> Java Versions support</h3> JDK Version</th> API Status</th> Enabling Preview Features</th> Key Enhancements (FFM API versions)</th> Package</th></tr></thead> JDK 14</td> Foreign-Memory Access API (Incubator)</td> Not applicable (Incubator)</td> Memory segments, Arenas (via Foreign-Memory Access API)</td> jdk.incubator.foreign</a></td></tr> JDK 16</td> Incubator</td> Not applicable (Incubator)</td> Calling native functions (via Foreign Linker API)</td> jdk.incubator.foreign</a></td></tr> JDK 17</td> Incubator</td> Not applicable (Incubator)</td> Unified FFM API, enhancements to MemorySegment and MemoryAddress abstractions, improved memory layout hierarchy</td> jdk.incubator.foreign</a></td></tr> JDK 18</td> Incubator</td> Not applicable (Incubator)</td> Refinements based on feedback</td> jdk.incubator.foreign</a></td></tr> JDK 19</td> Preview</td> –enable-preview flag required</td> Refinements based on feedback</td> java.lang.foreign</a></td></tr> JDK 20</td> Second Preview</td> –enable-preview flag required</td> Refinements based on feedback, including linker option for heap segments, Enable-Native-Access attribute, programmatic function descriptors</td> java.lang.foreign</a></td></tr> JDK 21</td> Third Preview</td> –enable-preview flag required</td> Further refinements based on feedback</td> java.lang.foreign</a></td></tr> JDK 22+</td> Finalized</td> Not required (Finalized)</td> API stabilization, minor refinements</td> java.lang.foreign</a></td></tr> </tbody></table> Explanation Incubator Phase: The initial steps of the FFM API were as incubating features, meaning they were experimental and subject to change. These releases introduced the core concepts like memory access and foreign function invocation. JEP 434 mentions that the FFM API was in its incubator phase in JDK 17 and JDK 18.</li> Preview Phase: In the preview phase, the API's design and implementation were complete, but still subject to potential changes based on user feedback. OpenJDK JEP 424 describes the Foreign Function & Memory API as a preview API in JDK 19.</li> Finalized: In JDK 22, the FFM API was declared stable and ready for production use, removing the need for preview flags and providing a more robust and reliable native interoperability solution.</li> Key Enhancements: This section highlights the significant changes and refinements introduced in each version of the FFM API as it evolved.</li> </ul> 📝 Walking Through FfmReceiver — A First Taste of Java FFM (AI generated)</h3> In this demo, we’re calling native io_uring functions in C from Java, to build a high-performance TCP receiver. 1. Arena</code> — Memory Lifetime Manager try (Arena arena = Arena.ofShared()) { ... } </code></pre> Arena is a memory allocator with automatic cleanup. </li> Think of it as a “scope for native memory”: allocate native buffers inside it, and when the try</code> block exits, the arena frees them automatically. </li> Variants: </li> </ul> Arena Type</th> Bounded Lifetime</th> Manual Close (arena.close())</th> Thread Access</th> Common Use Case</th></tr></thead> Global</td> No</td> No</td> Yes (accessible by any thread)</td> For memory that needs to persist for the entire lifetime of the application.</td></tr> Automatic</td> Yes</td> No (managed by Garbage Collector)</td> Yes (accessible by any thread)</td> Simplest memory management for bounded lifetimes. The memory is deallocated when the arena becomes unreachable by the garbage collector.</td></tr> Confined</td> Yes</td> Yes (mandatory)</td> No (only by the creating thread)</td> Perfect for single-threaded applications. Provides deterministic deallocation of memory when the arena is closed, often used with try-with-resources.</td></tr> Shared</td> Yes</td> Yes (mandatory)</td> Yes (accessible by multiple threads)</td> For concurrent applications where memory segments must be shared between threads. Closing the arena is safe and atomic, even when accessed by multiple threads.</td></tr> </tbody></table> Here we use ofShared()</code> because multiple native calls may work with the allocated memory. 2. SymbolLookup</code> — Finding Functions in a Shared Library SymbolLookup lib = SymbolLookup.libraryLookup("./libiouring_tcpa.so", arena); </code></pre> SymbolLookup</code> is how Java finds functions or variables inside a native shared library (.so</code>, .dll</code>, .dylib</code>).</li> You pass the library name and a scope (arena</code>).</li> Later, we’ll do lib.find("io_uring_listen")</code> to grab the raw address of that function.</li> </ul> 👉 Without SymbolLookup</code>, Java wouldn’t know where in memory the C function lives. 3. Linker</code> — Bridging Java ↔ Native Linker linker = Linker.nativeLinker(); </code></pre> Linker builds a bridge between Java and C functions.</li> It knows how to: Translate Java values to C values (e.g., int</code> ↔ int32_t</code>)</li> Call into native functions and return values back</li> </ul> </li> </ul> nativeLinker()</code> automatically picks the system ABI (x86_64, ARM64, etc.). 4. MemorySegment</code> — Safe, Structured Native Memory MemorySegment buffer = arena.allocate(bufferSize); </code></pre> MemorySegment is a safe view of native memory.</li> Unlike ByteBuffer</code> (which is limited and unsafe), a MemorySegment</code> tracks bounds, lifetime, and thread access.</li> Example:</li> </ul> byte b = buffer.get(ValueLayout.Java_BYTE, offset); buffer.set(ValueLayout.Java_BYTE, offset, (byte) 42); </code></pre> Here, we allocate an 8 MB receive buffer per client.</li> Later, we copy received bytes into a Java byte[]</code> for debugging.</li> </ul> 5. MethodHandle</code> — Calling Native Functions Every native function we call has 3 steps: Find its address:</li> </ol> MemorySegment addr = lib.find("io_uring_global_init").get(); </code></pre> Describe its signature using FunctionDescriptor</code>:</li> </ol> FunctionDescriptor.of(ValueLayout.Java_INT, ValueLayout.Java_INT) </code></pre> → “returns int, takes an int argument” Bind with a MethodHandle</code>:</li> </ol> MethodHandle mhGlobalInit = linker.downcallHandle(globalInitAddr, descriptor); </code></pre> Call it like a Java method:</li> </ol> int ret = (int) mhGlobalInit.invokeExact(queueDepth); </code></pre> 👉 A MethodHandle</code> is like a strongly-typed function pointer. It hides the messy details of JNI — no boilerplate, no unsafe casts. 6. ValueLayout</code> — Mapping Java ↔ C Types ValueLayout</code> tells the FFM API how Java types map to C types.</li> Examples: Java_INT</code> → C int32_t</code></li> Java_LONG</code> → C int64_t</code></li> Java_BYTE</code> → C int8_t</code></li> ADDRESS</code> → C pointers</li> </ul> </li> </ul> So when we say: FunctionDescriptor.of(ValueLayout.Java_INT, ValueLayout.Java_INT, ValueLayout.ADDRESS, ValueLayout.Java_LONG) </code></pre> We mean: int io_uring_recv(int clientFd, void* buffer, long length); </code></pre> 7. Putting It All Together In the demo flow: Initialize io_uring</li> </ol> mhGlobalInit.invokeExact(queueDepth); </code></pre> Create a TCP server socket</li> </ol> int listenFd = (int) mhListen.invokeExact(port, backlog); </code></pre> Accept connections</li> </ol> int clientFd = (int) mhAccept.invokeExact(listenFd); </code></pre> Receive data into a native buffer</li> </ol> int bytesReceived = (int) mhRecv.invokeExact(clientFd, buffer, bufferSize); </code></pre> Inspect data in Java (first 128 bytes)</li> </ol> byte[] arr = new byte[displayLen]; arr[i] = buffer.get(BYTE, i); </code></pre> Close the socket</li> </ol> mhClose.invokeExact(clientFd); </code></pre> 8. Why This Matters Traditionally, Java needed JNI for native calls — painful, verbose, unsafe. With FFM, we now have: Memory safety (bounds checks, lifetime control)</li> Performance (zero-copy native memory access)</li> Clarity (call native functions like Java methods)</li> Portability (same code runs across OS/CPU with correct ABI handling)</li> </ul> This demo shows: pure Java controlling a high-performance Linux feature (io_uring) — something unimaginable/complex with old JNI boilerplate.

Appendix</h1>

roray.dev - ffm

MYRA stack - modern JAVA FFM based libraries

Introducing MYRA: What I’ve Been Building</h1>

Why Java Instead of C/C++/Rust?</h2>
A common question: “If you need this kind of performance, why not just write it in C/C++/Rust?”</em></p>
It’s a fair question. The short answer: developer velocity, safety, and maintainability matter more than the last 5-10% of performance.</strong></p>

Java FFM - Foreign Function & Memory Access API (Project Panama)

TL;DR</h1>
Java’s Foreign Function & Memory (FFM) API enables safe, high-performance interaction with native code and memory, improving interoperability with other languages and access to low-level system resources. Entire source code available on GitHub</a>.

</p>

roray.dev - ffm

MYRA stack - modern JAVA FFM based libraries

Introducing MYRA: What I’ve Been Building</h1>

Why Java Instead of C/C++/Rust?</h2> A common question: “If you need this kind of performance, why not just write it in C/C++/Rust?”</em></p> It’s a fair question. The short answer: developer velocity, safety, and maintainability matter more than the last 5-10% of performance.</strong></p>

Java FFM - Foreign Function & Memory Access API (Project Panama)

TL;DR</h1> Java’s Foreign Function & Memory (FFM) API enables safe, high-performance interaction with native code and memory, improving interoperability with other languages and access to low-level system resources. Entire source code available on GitHub</a>. </p>

Appendix</h1>

Why Java Instead of C/C++/Rust?</h2>
A common question: “If you need this kind of performance, why not just write it in C/C++/Rust?”</em></p>
It’s a fair question. The short answer: developer velocity, safety, and maintainability matter more than the last 5-10% of performance.</strong></p>

TL;DR</h1>
Java’s Foreign Function & Memory (FFM) API enables safe, high-performance interaction with native code and memory, improving interoperability with other languages and access to low-level system resources. Entire source code available on GitHub</a>.

</p>