On Wed, 3 Jun 2026 08:50:01 GMT, Per Minborg <[email protected]> wrote:
> ## Summary > > This PR proposes to introduce a pooled confined arena as an optimization for > `Arena.ofConfined()`, where small native allocations can be served from a > reusable per-thread memory pool or a local arena pool instead of calling the > regular native allocator for every short-lived arena. The arena remains > confined to its owner thread and is still closed normally, but its backing > storage can be reset and reused when the arena closes. The feature requires > no API changes. > > ### Outline > > Platform threads: There are up to eight (four by default) lazily allocated > pools per Thread, encoded in `Thread.FieldHolder.confinedMemoryPool`. > Virtual threads: Works in the same way but uses its _carrier thread's _ cache > instead. > > Pooled memory is zeroed out upon _closing_ an Arena to minimize data > visibility between reuse. This means the data is visible only within a TWR > block, and never outside it. > > A confined arena has access to one, two, four, or eight (four by default) > platform/carrier thread pools, each of size 64 bytes by default. The pool > sizes are configurable via an internal unsupported system property and can be > 8 bytes .. 1 MiB. Pooling can also be turned off completely by setting the > pool properties to negative values. As there can be up to eight pools per > thread, nested confined arenas backed by thread-cached pools are supported > (i.e., up to eight nested arenas). > > ## Static Analysis > > An extensive static corpus analysis of third-party libraries and the JDK > itself has been conducted with respect to `Area.ofConfined()` usage, > revealing that confined arenas were used _only_ in TWR blocks and _never_ in > an unstructured way. The static analysis further revealed that in most cases, > only a small amount of native memory was ever allocated, usually less than 32 > bytes, and in many cases, 8 bytes or less. This usage pattern lends itself > well to pooling. > > ## Dynamic Analysis > > A dynamic statistical analysis of actual runs was also made, where various > properties of confined arenas were recorded and summarized during a complete > tier1 test run. While a tier1 run is not necessarily representative of a > typical application workload, it provided some interesting results: Except > for very large allocations, >99% were smaller than 64 bytes. Almost 50% > didn't allocate any memory, indicating a lazy approach would pay off. > > The above data supports that picking a 64-byte-sized pool would enable most > allocations to be served from the pool. > > ## Performance > > Pooling improves tiny confi... This pull request has now been integrated. Changeset: e9222ab5 Author: Per Minborg <[email protected]> URL: https://git.openjdk.org/jdk/commit/e9222ab58987711adafd598a01b7ad58ab25f895 Stats: 1963 lines in 17 files changed: 1945 ins; 3 del; 15 mod 8385697: Add a Pooled Confined Arena Reviewed-by: jvernee, alanb ------------- PR: https://git.openjdk.org/jdk/pull/31365
