JEP draft: Scope Locals

[Brian Goetz]

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
>