This is blocked by #15486

@normanmaurer @chrisvest I see that adaptive is using mostly unpooled direct ByteBuf, whilst the "old" allocator PooledDirectByteBuf - which means that I should "fix" that one too - let me know wdyt?

The improvements, so far (at b2824591d322770f81f633fff11eb65142de4628) are:

                                                     BEFORE         |       AFTER
Benchmark                                      Score   Error  Units | Score   Error  Units 
ByteBufAccessBenchmark.getBytes                7.020 ± 0.136  ns/op | 4.573 ± 0.135  ns/op
ByteBufAccessBenchmark.getBytesConstantOffset  5.856 ± 0.296  ns/op | 4.853 ± 0.029  ns/op
ByteBufAccessBenchmark.readBytes               6.708 ± 0.030  ns/op | 5.694 ± 0.097  ns/op
ByteBufAccessBenchmark.setBytes                9.082 ± 0.097  ns/op | 6.149 ± 0.076  ns/op
ByteBufAccessBenchmark.setBytesConstantOffset  7.143 ± 0.069  ns/op | 5.195 ± 0.340  ns/op

whilst the batchy numbers are still far behind Unsafe (reported in the related issue) because we now have an unrolling of 4 instead of 8.

@chrisvest
The funny thing is: if we have cleaners which wraps MemorySegment - and under the hood NIO Direct buffers uses such - maybe we could just do the same and re-use the one in the clearner, slicing it and using it instead of the NIO buffer.

I have to perform few benchmarks vs MemorySegment but I can see already that some of the benchmarks I did requires reading buffer -> segment + limit + capacity

@normanmaurer @chrisvest for this, do I need to care about the jemalloc pooled buffers as well?

Fyi I have tried before/after just with JDK 24 but it could be worthy to try with 11/17 as well - which meant doesn't have that good varHandle optimizations.
Right now this improve the adaptive case only and in theory I can push this beyond what it does by having a segment based buffer too

do I need to care about the jemalloc pooled buffers as well?

I think it's fine to at least do them one at a time, in separate PRs. The pooled allocator will be used for cases where the adaptive allocator turns out to be a poor fit, and as an intermediate step in upgrading systems from 4.1 to 4.2.

@franz1981 please rebase

Done ptal @normanmaurer

If this look good @chrisvest we can go for it?

Thanks, Franz!