VirtualThread(s) context lookup relies on ThreadLocal(s)

[franz1981]

Version

latest 5.x and 4.x

Context

https://github.com/eclipse-vertx/vert.x/blob/master/vertx-core/src/main/java/io/vertx/core/impl/VertxImpl.java#L101-L104 shows that while creating virtual threads from other virtual threads we would use ThreadLocal(s) - which is a bad pattern due to the heavyweight nature of TL w Loom.
See netty/netty#13191 and quarkusio/quarkus#39696
There are few option(s) here:

• using CHM (which is not great I know) but it requires been in control of the whole VT lifecycle to be able to remove the VT from the CHM on completion
• using ScopedValue (in some creative ways e.g. https://github.com/franz1981/Netty-VirtualThread-Scheduler/blob/7b9b122572676c65e51aa40ce5afbdf1fbcb7afb/core/src/main/java/io/netty/loom/EventLoopScheduler.java#L93) - but similarly requires to be in control of the VT lifecycle

IDK how to better fix it, since it's purpose is to propagate the context (see

vert.x/vertx-core/src/main/java/io/vertx/core/impl/VertxImpl.java

Line 481 in 7b1c42e

ContextDispatch current = nonVertxContextDispatch.get();

), but we can think of a better and more performant way for sure.

Steps to reproduce

No response

Do you have a reproducer?

No response

[franz1981]

For Netty 4.2 we changed how Fast thread local(s) are detected and used and it's possible to run virtual threads runnable as fast thread local threads (using a CHM) and leverage fast thread local lookups for them.
This would enable to use a faster but still semi-transparent mechanism for context passing/lookup