Apart the performance, threadLocal has currently two issues that are addressed by scope locals.
ThreadLocal let the programmer defines the lifecycle, while it seems great on paper, it's a huge mess in reality. Because not everybody wraps the calls to set()/remove() in a try/finally, so the values inside thread locals are not reclaimed by the GC. It was less an issue before pooling because all the values are reclaimed when the thread die, but with pooling, threads do not die. (I think this is the point made by Brian about ThreadLocal not interacting smoothly with ThreadLocal) InheritableThreadLocal copies everything each time a new thread is created, again this lead to memory leaks because if an unexpected threads is created, sadly some libraries do that, all values are now referenced by this new thread that may never die. If you want more https://www.google.com/search?hl=en&q=ThreadLocal%20memory%20leak I think the JEP should be more explicit about the shortcoming of ThreadLocal and how the design of scope local fix both issues. Rémi ----- Mail original ----- > De: "Brian Goetz" <brian.go...@oracle.com> > À: "Andrew Haley" <a...@redhat.com>, "core-libs-dev" > <core-libs-dev@openjdk.java.net>, "loom-dev" > <loom-...@openjdk.java.net> > Envoyé: Mercredi 12 Mai 2021 20:57:33 > Objet: Re: JEP draft: Scope Locals > Scope locals have come together nicely. > > I have some vague thoughts on the presentation of the JEP draft. There > are (at least) three intertwined things in the motivation: > > - ThreadLocal (and ITL especially) were always compromises, and with > the advent of Loom, have become untenable -- but the need for implicit > parameters has not gone away > - Scoped locals, because of their effective finality and dynamic > scoping, offer a programming model that is a better fit for virtual > threads, but, even in the absence of virtual threads, are an enabler for > structured concurrency > - The programming model constraints enable a better-performing > implementation > > In reading the draft, these separate motivations seem somewhat tangled. > All the words make sense, but a reader has a hard time coming away with > a clear picture of "so, why did we do this exactly, besides that its > cool and faster?" > > A possible way to untangle this is: > > - the underlying use cases: various forms of implicit context > (transaction context, implicit parameters, leaving breadcrumbs for your > future self.) > - the existing solution: thread locals. ThreadLocals are effectively > mutable per-thread globals. The unconstrained mutability makes them > hard to optimize. ThreadLocals interact poorly with pooled threads. > - Here comes Loom! We no longer need to pool threads. So, why are > TLs not good enough? > - The more constrained programming model of SLs enables two big new > benefits: > - structured concurrency, which is applicable to virtual and > non-virtual threads alike > - better optimization of inheritance and get operations > > > > > > > > On 5/12/2021 10:42 AM, Andrew Haley wrote: >> There's been considerable discussion about scope locals on the loom-dev list, >> and it's now time to open this to a wider audience. This subject is important >> because. although scope locals were motivated by the the needs of Loom, they >> have many potential applications outside that project. >> >> The draft JEP is at >> >> https://bugs.openjdk.java.net/browse/JDK-8263012 >> >> I've already received some very helpful suggestions for enhancements to >> the API, and it'll take me a while to work through them all. In particular, >> Paul Sandoz has suggested that I unify the classes Snapshot and Carrier, >> and it will take me some time to understand the consequences of that. >> >> In the meantime, please have a look at the JEP and comment here. >> >> >> For reference, earlier discussions are at >> >> https://mail.openjdk.java.net/pipermail/loom-dev/2021-March/002268.html >> https://mail.openjdk.java.net/pipermail/loom-dev/2021-April/002287.html >> https://mail.openjdk.java.net/pipermail/loom-dev/2021-May/002427.html
