Scoped variables

[Doug Lea]

On 12/5/18 5:15 AM, Andrew Haley wrote:
> there is (usually) a register pointing to the current VM thread metadata.
> Thread.currentThread() is a field in that structure.

Separately from other issues ...

The possible need for different kinds of variables stems from in part
the issue that if Fibers are Threads, then Thread.currentThread() might
return something that does not want to support some Thread methods or
fields. (Basically, this is a is-a vs has-a issue.)

Other lightweight execution frameworks (in JDK, most notably
ForkJoin{Pool,Task}) include methods to access task-, thread-, and
group/pool-level context, allowing multiple levels of context. People
using these frameworks seem to cope OK with this. They either avoid
using ThreadLocals for tasks that may run under unknown worker threads,
or use ThreadFactories to specially configure workers.

This was also one motivation for considering introducing CPU-locals, as
another form of context. Which would be handy in a few nichy cases but
would not be very helpful in replacing the "builtin" Thread-locals for
ThreadLocalRandom and secondary seed/probe (used only by
java.util.concurrent). Because Fiber scheduling is not (and probably
cannot be) preemptive, unsynchronized thread-local updates of random
seeds etc would work fine even if fibers could move across threads.
Without further support like restartable regions, the same would not
hold for CPU-locals.

-Doug