--- title: Allocating Off-Heap Memory: Typically 6-18x Faster in JDK 28 description: JDK 28 makes off-heap memory allocation through the Foreign Function & Memory API dramatically faster for small, confined-arena allocations. Native-memory... canonical: https://daily.dev/posts/allocating-off-heap-memory-typically-6-18x-faster-in-jdk-28-5glikaj2e twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Allocating Off-Heap Memory: Typically 6-18x Faster in JDK 28 | daily.dev og:description: JDK 28 makes off-heap memory allocation through the Foreign Function & Memory API dramatically faster for small, confined-arena allocations. Native-memory... og:url: https://daily.dev/posts/allocating-off-heap-memory-typically-6-18x-faster-in-jdk-28-5glikaj2e og:image: https://api.daily.dev/og/posts/5gLIkAJ2E.png og:image:alt: Allocating Off-Heap Memory: Typically 6-18x Faster in JDK 28 og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Allocating Off-Heap Memory: Typically 6-18x Faster in JDK 28 **[Inside Java](https://daily.dev/sources/inside_java)** · 7 min read · 0 upvotes · 0 comments ## Summary JDK 28 makes off-heap memory allocation through the Foreign Function & Memory API dramatically faster for small, confined-arena allocations. Native-memory pools now serve small allocations on Windows, Mac, and Linux, cutting allocation latency by up to 90%. No source code changes are needed and the existing safety guarantees of confined arenas are preserved. Development benchmarks show 5-byte allocation speedups ranging from 6.8x on Linux x64 to 18.6x on macOS AArch64, and 20-byte speedups up to 18.9x on Windows x64. Allocations above the default 64-byte pool size fall back to the regular allocation path with no change. The optimization only applies to confined arenas, not other arena types. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### Does JDK 28 require code changes to get faster off-heap allocation with the FFM API? No code changes are required. JDK 28 automatically pools small allocations (up to 64 bytes) made through confined arenas created with Arena.ofConfined(), serving them from a per-thread native-memory cache instead of calling the native allocator each time. This can reduce allocation latency by up to 90% while preserving all existing safety and lifetime guarantees. _Teams planning a JDK 28 upgrade can track FFM performance changes like this on daily.dev._ ### How much faster is confined arena allocation in JDK 28 compared to older JDK versions? Benchmarks show speedups of roughly 6.8x to 18.9x for small allocations (5 and 20 bytes) across platforms. Linux x64 saw about 6.8x for 5-byte allocations and 7.8x for 20-byte allocations, while macOS AArch64 reached 18.6x and 16.8x, and Windows x64 reached 16.8x and 18.9x respectively. Allocations above the default 64-byte pool size see no change, since they use the regular allocation path. _Developers benchmarking JVM upgrades can follow native-interop performance data like this on daily.dev._ ### Do pooled confined arenas in JDK 28 work with virtual threads? Yes, but with some overhead. A virtual thread temporarily borrows a native-memory pool from its current carrier thread rather than maintaining its own cache, which would hurt the small footprint virtual threads are designed for. The virtual thread is pinned only during the brief handoff, and benchmarks still showed substantial speedups over non-pooled allocation despite added carrier-handling overhead. _Those building high-throughput virtual-thread services can track FFM and concurrency updates like this on daily.dev._ ## Similar posts on daily.dev - [Making \`Arena.ofConfined\(\)\` Even Cheaper in JDK 28](https://daily.dev/posts/making-arena-ofconfined-even-cheaper-in-jdk-28-jp5eqpooo) · Inside Java · 3 upvotes · 0 comments - [Native Memory in Java: Arenas, Malloc, and Pools](https://daily.dev/posts/native-memory-in-java-arenas-malloc-and-pools-hyaefjfpb) · Foojay.io · 1 upvotes · 0 comments - [Pointer Arithmetic in Modern Java](https://daily.dev/posts/pointer-arithmetic-in-modern-java-2c5ccltz0) · Foojay.io · 0 upvotes · 0 comments - [Internals for Interns](https://daily.dev/posts/internals-for-interns-fg0xibngw) · Hacker News · 0 upvotes · 0 comments --- Tags: [#performance](https://daily.dev/tags/performance), [#java](https://daily.dev/tags/java) [View this post on daily.dev](https://daily.dev/posts/allocating-off-heap-memory-typically-6-18x-faster-in-jdk-28-5glikaj2e) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"Allocating Off-Heap Memory: Typically 6-18x Faster in JDK 28","url":"https://daily.dev/posts/allocating-off-heap-memory-typically-6-18x-faster-in-jdk-28-5glikaj2e","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/allocating-off-heap-memory-typically-6-18x-faster-in-jdk-28-5glikaj2e"},"datePublished":"2026-10-23T07:26:18.779Z","dateModified":"2026-10-23T07:26:48.787Z","description":"JDK 28 makes off-heap memory allocation through the Foreign Function \u0026 Memory API dramatically faster for small, confined-arena allocations. Native-memory...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/8a590c6abfe6299c110ce5c325f2383e?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/8a590c6abfe6299c110ce5c325f2383e?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Inside Java","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Inside Java","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1/logos/de5992d95f374790bdfd2ae03a16f6e3","url":"https://daily.dev/sources/inside_java"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/allocating-off-heap-memory-typically-6-18x-faster-in-jdk-28-5glikaj2e","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"performance,java","timeRequired":"PT7M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Inside Java","item":"https://daily.dev/sources/inside_java"},{"@type":"ListItem","position":3,"name":"Allocating Off-Heap Memory: Typically 6-18x Faster in JDK 28"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/allocating-off-heap-memory-typically-6-18x-faster-in-jdk-28-5glikaj2e#faq","mainEntity":[{"@type":"Question","name":"Does JDK 28 require code changes to get faster off-heap allocation with the FFM API?","acceptedAnswer":{"@type":"Answer","text":"No code changes are required. JDK 28 automatically pools small allocations (up to 64 bytes) made through confined arenas created with Arena.ofConfined(), serving them from a per-thread native-memory cache instead of calling the native allocator each time. This can reduce allocation latency by up to 90% while preserving all existing safety and lifetime guarantees. Teams planning a JDK 28 upgrade can track FFM performance changes like this on daily.dev."}},{"@type":"Question","name":"How much faster is confined arena allocation in JDK 28 compared to older JDK versions?","acceptedAnswer":{"@type":"Answer","text":"Benchmarks show speedups of roughly 6.8x to 18.9x for small allocations (5 and 20 bytes) across platforms. Linux x64 saw about 6.8x for 5-byte allocations and 7.8x for 20-byte allocations, while macOS AArch64 reached 18.6x and 16.8x, and Windows x64 reached 16.8x and 18.9x respectively. Allocations above the default 64-byte pool size see no change, since they use the regular allocation path. Developers benchmarking JVM upgrades can follow native-interop performance data like this on daily.dev."}},{"@type":"Question","name":"Do pooled confined arenas in JDK 28 work with virtual threads?","acceptedAnswer":{"@type":"Answer","text":"Yes, but with some overhead. A virtual thread temporarily borrows a native-memory pool from its current carrier thread rather than maintaining its own cache, which would hurt the small footprint virtual threads are designed for. The virtual thread is pinned only during the brief handoff, and benchmarks still showed substantial speedups over non-pooled allocation despite added carrier-handling overhead. Those building high-throughput virtual-thread services can track FFM and concurrency updates like this on daily.dev."}}]} ```