SmallRyeThreadContext's close can use custom cleanup strategies #424
Description
I've spotted this In few reactive benchmarks using quarkus which doesn't disable context propagation (fairly commons for users that don't change default I believe): from what i can see there (and the code confirm it) the behaviour of SmallRyeThreadContext on close is to call ThreadLocal's removal, in order to save leaks to happen.
Sadly ThreadLocal::remove have a huge impact perf wise due to
https://github.com/openjdk/jdk19/blob/967a28c3d85fdde6d5eb48aa0edd8f7597772469/src/java.base/share/classes/java/lang/ThreadLocal.java#L570
which end up calling Reference::clear via
that can be seen in this flamegraph (in violet)
and at a deeper level
which show the interaction with the runtime to coordinate an async cleanup (it's a weak ref :"/ sob)
Given that such cost happen in the I/O thread it can be pretty severe and should be better saving it.
I order to improve this, would be great to be able to configure SmallRyeThreadContext via a lambda (once or more time) which can allow an external framework to perform some check to guide the close operation to perform a much cheaper set(null) (which doesn't remove the entry) or full fat remove as it is now: in the quarkus use case I think that if such lambda can query if the context of execution is within an I/O event loop thread (not just on a vertx ctx!), there won't be any need to remove the thread local entirely, because I/O threads will be alive for the whole application life-time.