JBossThread (off-heap) memory footprint due to FastThreadLocal usage

[franz1981]

The blocking thread pool of Quarkus is extending Netty's FastThreadLocalThread for several reasons (@cescoffier knows more on this), but it leads to 2 problems:

• Increase the (off-heap) memory footprint of our Quarkus instances due to both Netty's Recyclers and, even worse, PoolThreadCache (at https://github.com/netty/netty/blob/4ba1c3e7e190bdc9bdd0ece237042f16e843c797/buffer/src/main/java/io/netty/buffer/PooledByteBufAllocator.java#L525) which can become pretty big and stay still on idle threads too, without being available to others
• In case idle (non-core) threads get killed and recreated, new PoolThreadCaches allocations can still cause extending existing allocation(s) off-heap arena, which with glibc, can cause a spike in memory usage (more info at https://sourceware.org/bugzilla/show_bug.cgi?id=11261)

Ideally if jboss-thread(s) Threads won't be FastThreadLocalThreads it will just work fine, because useCacheForAllThreads is false by default. Another option, instead, similar to #39061, is to use heap-based unpooled buffers, but given that core jboss-thread(s) are long living, will likely impact performance.

There's another option to investigate which periodically schedule trimming of thread local caches (see https://github.com/netty/netty/blob/4ba1c3e7e190bdc9bdd0ece237042f16e843c797/buffer/src/main/java/io/netty/buffer/PooledByteBufAllocator.java#L127-L145), but sadly it will be applied to event loops/I/O threads too, which is not something we want (I believe).

[franz1981]

@vietj too

[quarkus-bot]

/cc @Sanne (core), @aloubyansky (core), @gsmet (core), @radcortez (core), @stuartwdouglas (core)

[Sanne]

Great find. I migth be wrong, but this seems very important to urgently - labelling.