Your TLS Stack Is Lying to You About Zero-Copy
This title could be clearer and more informative.Try out Clickbait Shieldfor free (5 uses left this month).
A deep dive into why SSLEngine becomes an architectural mismatch in a zero-allocation JVM runtime (the Exeris Kernel). The author explains how SSLEngine's heap-facing ByteBuffer contract undermines off-heap ownership semantics, then shows an alternative using Java's Project Panama FFM (Foreign Function & Memory) API to call OpenSSL natively. JMH benchmarks compare four TLS architectures: JDK SSLEngine (~905k ops/s, 2528 B/op allocation), Netty tcnative (~856k ops/s, 560 B/op), Exeris FFM Memory BIO (~922k ops/s, 0 B/op), and Exeris FFM FD Owner (~367k ops/s, 0 B/op). The key finding is that SSLEngine allocates over 2.5KB of heap garbage per 1KB TLS record, silently undermining a zero-allocation hot path. The author acknowledges SSLEngine remains the right choice for most Java services, but argues that for a runtime with strict off-heap ownership and deterministic cleanup requirements, native FFM-based TLS is architecturally necessary.
