Thread-local successor for object pooling

[Volkan Yazıcı]

Is it safe to assume that the disableThreadLocals toggle will only be
released along with a decent alternative (e.g., ScopedValues)? Otherwise,
libraries relying on TLs will simply not work due to the thrown
UnsupportedOperationException. Put another way, Log4j can replace TLs that
serve object pooling purposes with something else, today; though for TLs
that are used to pass context, disableThreadLocals=true will simply render
them broken without a solution.

On Wed, Nov 2, 2022 at 11:30 AM Ron Pressler <ron.pressler at oracle.com>
wrote:

> There is no difference in capabilities or behaviour between virtual
> threads and platform threads when it comes to ThreadLocals. It’s just that
> because some particular uses of TLs make an implicit assumption about
> threads being shared and few in number, assumptions that are usually true
> for platform threads and usually untrue for virtual threads, we’ve added
> the possibility of disabling ThreadLocals for any kind of thread. By
> default, all threads allow TLs, and so running old code on virtual threads
> will work as before.
>
> 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. Many if not most uses of TLs — those that associate
> domain context with a task — are fine with virtual threads (although
> ScopedValues are much better). There is no need to deprecate ThreadLocal
> nor a plan to ever do so.
>
> — Ron
>
> On 2 Nov 2022, at 00:03, Carter Kozak <ckozak at ckozak.net> wrote:
>
> > 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/20221102/64e50eef/attachment-0001.htm>