JDK 28 Reduces Off-Heap Allocation Latency by Up to 90 Percent
A new thread-local caching mechanism in JDK 28 significantly accelerates small confined arena allocations across all major operating systems without requiring code changes.
JDK 28 drops allocation latency for small off-heap allocations in confined arenas by up to 90% on Windows, macOS, and Linux, according to a writeup by Per-Ake Minborg of the Java team on October 23, 2026. Code changes are not required, and safety guarantees remain unchanged.
Before JDK 28, even tiny allocations went through the regular native allocator and registered cleanup actions. Over 99.99% of confined arenas that allocated memory in one instrumented test-suite run used less than 64 bytes.
Each platform thread lazily maintains a small cache holding up to four pools of 64 bytes each by default. An arena takes a pool on its first qualifying allocation. When the arena closes, the used portion of the pool is zeroed and returned to the thread cache, or back to the native allocator if the cache is full. Virtual threads borrow pools from their current carrier threads.
Development benchmarks measured speedups from 6.8x to 18.9x for 5-byte and 20-byte allocations:
| Platform | 5-byte | 20-byte |
|---|---|---|
| Linux AArch64 | 12.3x | 8.6x |
| Linux x64 | 6.8x | 7.8x |
| macOS AArch64 | 18.6x | 16.8x |
| Windows x64 | 16.8x | 18.9x |
On an Apple M4 running macOS, a 5-byte confined allocation took 1.05 ns with pooling versus 15.9 ns without it. Allocations of 100 bytes and above stay at previous speeds.
The work is tracked as JDK-8385697.