Thread-local successor for object pooling

[Carter Kozak]

> That's right but not specific to virtual threads. It is also possible to 
> create platform threads that do not support TLs. This is something that  
> we need a lot more feedback on before deciding if that part of the API 
> should be made permanent.

This is an interesting point. I'm not sure I understand why the introduction of virtual threads is the best place to make the ThreadLocal language feature configurable, but I'd appreciate additional context.
The JEP describes the motivation for the dynamic configuration of ThreadLocals, as well as an alternative (jep-429 scoped values), however the behavior seems (to an outsider) to oppose the higher-level design of virtual threads which are meant to be otherwise a drop-in replacement for platform threads. I'd much rather fail predictably (or in a way the compiler can warn me about) rather than when a legacy function compiled with jdk1.5 executes on a particular type of thread.
Given that using virtual threads is going to be a decision that happens in isolation from code that may use ThreadLocals, ideally we could introduce alternatives to ThreadLocal safely in an LTS before making ThreadLocal throw. Then, we could add the configuration point to disable ThreadLocals (on all types of thread?) and/or for potentially greater consistency, deprecate ThreadLocal for removal.

> It would be interesting to know if log4j has done any recent evaluation
> with newer JDK releases and GCs to see their object pooling has a
> positive or negative benefit.

Yes, it's complicated. Performance has certainly changed over time with JDK releases and the benefits are use-case dependent. The primary benefit is isolation (lack of impact on GC, which itself may impact seemingly unrelated components).

Thanks,
Carter Kozak
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20221101/02752678/attachment-0001.htm>