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
