Consider the following case of invoking strlen using FFM:

MethodHandle STRLEN = ...

try (Arena arena = Arena.ofConfined()) {
    MemorySegment str = arena.allocateFrom("Hello!");
    STRLEN.invokeExact(str);
}

Here, we need to create a new confined arena to allocate the off-heap string that needs to be passed to strlen.

There are, however, some performance issues with this (common) approach. The main issue is that `Arena::allocate` will call malloc, which is (likely) too slow in cases, like this, where the memory is disposed immediately after the native call (in such cases a C developer will probably use stack allocation instead, for the same reasons).

While developers can create custom arenas, e.g. using SegmentAllocator::slicingAllocator, it is rather hard to construct an allocator that exhibit good performance characteristics while providing a good amount of reuse. While in principle reuse could be achieved by using e.g. a ThreadLocal, the existence of virtual threads might pose scalability issues that might prevent developers from going down that road. While the JDK has better sharing mechanism internally (e.g. TerminatingThreadLocal), such mechanisms are not accessible outside, and for good reasons, as they are fundamentally unsafe (e.g. they can be used to attach custom operations to thread exit).

For this reason, it would be beneficial if FFM provided a bespoke solution for emulating the performance of stack allocation, but using arenas. A possible API would work like this:

static final StackPool MY_POOL = new StackPool();

...

try (Arena arena = MY_POOL.get()) { // get an arena from the pool for the current thread
    MemorySegment str = arena.allocateFrom("Hello!"); // recycle memory (where possible)
    STRLEN.invokeExact(str);
} // release memory back to the pool

If done correctly, we estimate that this could cut the execution time of code like this in half.