Thread-local successor for object pooling

[Carter Kozak]

Thank you all for such insightful replies and additional context.

Firstly, I’d like to clarify that I (and I believe everyone else involved this thread) agrees that using ThreadLocals as caches no longer makes sense in a post-loom world. ThreadLocal caches are dubious even now, we have better options in cases which necessitate pooling.

> There is no need to deprecate ThreadLocal nor a plan to ever do so.

My fear, however, is that by making ThreadLocal support on a per-thread basis configurable, we make them dangerous to use in any code that cannot be directly traced to thread creation (all library code). While the current proposal does not deprecate ThreadLocal, I would argue that they become de facto deprecated once they’re no longer guaranteed to work depending on external factors (the thread an external caller used).

> Just to be clear, there is nothing *fundamentally* wrong about TLs, nor their use in virtual threads. It’s just that thread usage patterns have led to *some* TL usage patterns that would be problematic with common virtual thread usage patterns.

Based on this description, we’re risking a great deal of collateral damage in order to support an option to help reduce a suboptimal usage pattern. My read (as an outsider, without as much context as many of you!) is that the risk/reward trade-off doesn’t compare favorably to allowing code that’s executed in a new way to display new performance characteristics, which will lead to code changes eliminating bad patterns in places where it matters.

> Another option on the table at the time was for TL.set (the only method that throws) to be a no-op so that TL.get always returns the initial value.

This is subtler API break where failures still occur at runtime but in a way that’s less obvious, potentially impacting correctness/security in unexpected ways.

> the question on whether we should continue to allow opt-out of thread locals when creating threads is an issue where more feedback is required.

My intent is to provide feedback based on my experience and set of use-cases that I'm familiar with, in the hope that we can come to the most reasonable solution for everyone.

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