<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
<div class="">I’d like to explain what the problem is, because I think it’s the most important thing. The mechanism of associating data with the thread is not the main issue. The problem is *what* data is associated with a thread. Associating context-specific
data, i.e. task-specific data with a thread is fine. The problem is associating data with a thread that is *not* task-specific, i.e. data that is to be shared among multiple tasks.</div>
<div class=""><br class="">
</div>
<div class="">The solution to that problem is not offering an alternative mechanism for associating data with a thread, but getting people to stop doing that altogether: data that needs to be shared among multiple tasks should *not* be associated with a thread.
Others have suggested using pools based on concurrent data structures, and those would work (we might someday offer more efficient pools, but those still would not be alternatives to thread locals in the sense that they will not associate data with threads).</div>
<div class=""><br class="">
</div>
<div class="">Similarly, disabling thread locals is not a problem here. Whether thread locals are disabled or not, if code associates task-shared data with a thread, the application will misbehave (by introducing large footprint and initialisation overheads)
when every task has its own thread, even with thread locals enabled. Again, the solution is to stop doing that.</div>
<div class=""><br class="">
</div>
<div class="">On the other hand, associating *task-specific* data with a thread is fine, whether using TLs (which aren’t going away) or more efficient and correct alternatives like ScopedValues. The option to disallow thread locals is intended for specialised
use-cases that *want* to forbid TLs, and TLs are obviously allowed by default.</div>
<div class=""><br class="">
</div>
<div class="">In short: TLs are not a problem. The problem is associating shared caches with a thread, because threads are less likely to be shared. The alternative is to not do that (and rely on object pools where they’re found to actually help).</div>
<div class=""><br class="">
</div>
<div class="">— Ron</div>
<div><br class="">
<blockquote type="cite" class="">
<div class="">On 2 Nov 2022, at 14:38, Volkan Yazıcı <<a href="mailto:volkan@yazi.ci" class="">volkan@yazi.ci</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div dir="ltr" class="">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.<br class="">
</div>
<br class="">
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Wed, Nov 2, 2022 at 11:30 AM Ron Pressler <<a href="mailto:ron.pressler@oracle.com" class="">ron.pressler@oracle.com</a>> wrote:<br class="">
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div style="overflow-wrap: break-word;" class="">
<div style="margin:0px;font-stretch:normal;font-size:13px;line-height:normal;font-family:"Helvetica Neue"" class="">
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.</div>
<div style="margin:0px;font-stretch:normal;font-size:13px;line-height:normal;font-family:"Helvetica Neue";min-height:15px" class="">
<br class="">
</div>
<div style="margin:0px;font-stretch:normal;font-size:13px;line-height:normal;font-family:"Helvetica Neue"" class="">
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.</div>
<div style="margin:0px;font-stretch:normal;font-size:13px;line-height:normal;font-family:"Helvetica Neue"" class="">
<br class="">
</div>
<div style="margin:0px;font-stretch:normal;font-size:13px;line-height:normal;font-family:"Helvetica Neue"" class="">
— Ron</div>
<div class=""><br class="">
<blockquote type="cite" class="">
<div class="">On 2 Nov 2022, at 00:03, Carter Kozak <<a href="mailto:ckozak@ckozak.net" target="_blank" class="">ckozak@ckozak.net</a>> wrote:</div>
<br class="">
<div class="">
<div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none" class="">
<div class="">> That's right but not specific to virtual threads. It is also possible to <br class="">
</div>
<div class="">> create platform threads that do not support TLs. This is something that <br class="">
</div>
<div class="">> we need a lot more feedback on before deciding if that part of the API <br class="">
</div>
<div class="">> should be made permanent.<br class="">
</div>
<div class=""><br class="">
</div>
</div>
<div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none" class="">
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.<br class="">
</div>
<div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none" class="">
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.<br class="">
</div>
<div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none" class="">
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.<br class="">
</div>
<div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none" class="">
<br class="">
</div>
<div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none" class="">
<div class="">
<div class="">
<div class="">> It would be interesting to know if log4j has done any recent evaluation<br class="">
</div>
</div>
<div class="">> with newer JDK releases and GCs to see their object pooling has a<br class="">
</div>
<div class="">
<div class="">> positive or negative benefit.<br class="">
</div>
<div class=""><br class="">
</div>
</div>
<div class="">
<div class="">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).<br class="">
</div>
</div>
<div class=""><br class="">
</div>
<div class="">Thanks,<br class="">
</div>
<div class="">Carter Kozak</div>
</div>
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</blockquote>
</div>
</div>
</blockquote>
</div>
<br class="">
</body>
</html>