[foreign-jextract] RFR: MemorySegmentPool + Allocator

[Maurizio Cimadamore]

On Sat, 17 Apr 2021 20:53:41 GMT, Radoslaw Smogura <github.com+7535718+rsmogura at openjdk.org> wrote:

> (Preview)
> 
> The MemorySegmentPool is a pool maintaining memory segments, optionally can expose allocator which can be bound to other scope, and which will return allocated segments back to pool.
> 
> However the best results has been achieved by using getSegmentEntry & putSegmentEntry methods.
> 
> The pool is intended to be used by long running applications (i.e. like global shared pool), where fast allocation and de-allocation of segments is critical (was designed during implementation of I/O subsystem with Panama, as a pool for temporary buffers between system I/O methods and Java byte arrays from InputStreams).
> 
> The pool uses hand-made SpinLockQueue as the Deque from JDK offers too much functionality and overhead.

I've fetched the branch, and tried to hook it up on a benchmark we have (`StrLenTest`) which allocates a native string and calls strlen on it. Here are the results:


StrLenTest.panama_strlen                      5  avgt   30  113.616 ? 3.525  ns/op
StrLenTest.panama_strlen                     20  avgt   30  118.923 ? 0.881  ns/op
StrLenTest.panama_strlen                    100  avgt   30  148.828 ? 1.055  ns/op
StrLenTest.panama_strlen_arena                5  avgt   30   37.072 ? 1.336  ns/op
StrLenTest.panama_strlen_arena               20  avgt   30   46.380 ? 1.600  ns/op
StrLenTest.panama_strlen_arena              100  avgt   27   87.728 ? 4.565  ns/op
StrLenTest.panama_strlen_pool                 5  avgt   30   66.258 ? 0.744  ns/op
StrLenTest.panama_strlen_pool                20  avgt   30   69.817 ? 0.364  ns/op
StrLenTest.panama_strlen_pool               100  avgt   30   85.723 ? 0.966  ns/op
StrLenTest.panama_strlen_prefix               5  avgt   30   27.365 ? 0.536  ns/op
StrLenTest.panama_strlen_prefix              20  avgt   30   32.963 ? 0.439  ns/op
StrLenTest.panama_strlen_prefix             100  avgt   30   59.558 ? 1.001  ns/op
StrLenTest.panama_strlen_unsafe               5  avgt   30   40.098 ? 0.319  ns/op
StrLenTest.panama_strlen_unsafe              20  avgt   30   43.820 ? 0.598  ns/op
StrLenTest.panama_strlen_unsafe             100  avgt   30   63.797 ? 4.497  ns/op
StrLenTest.panama_strlen_unsafe_trivial       5  avgt   30   26.341 ? 0.266  ns/op
StrLenTest.panama_strlen_unsafe_trivial      20  avgt   30   32.249 ? 0.553  ns/op
StrLenTest.panama_strlen_unsafe_trivial     100  avgt   30   59.589 ? 0.772  ns/op


The pool solution seems to be 2x faster than plain usage of `MemorySegment::allocateNative`. That said, pooled allocation is still significantly slower than calling malloc outside the `MemorySegment` API (see `unsafe` benchmarks), and also slower than just writing the native string onto the same segment over and over (see `prefix` benchmarks). This was unexpected for me, as I thought this kind of benchmark was exactly the reason as to why one would be using pooled allocators?

-------------

PR: https://git.openjdk.java.net/panama-foreign/pull/509