On Thu, 3 Sep 2026 08:31:49 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. > ... > > Per Minborg has updated the pull request incrementally with one additional > commit since the last revision: > > Rework thread cleanup Marked as reviewed by jvernee (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/31365#pullrequestreview-5101807032
