Scoped variables

Andrew Haley aph at
Wed Aug 7 16:45:00 UTC 2019

On 7/19/19 1:21 PM, Ron Pressler wrote:

> We haven’t had much time to spend on this recently, and we certainly
> have no conclusions as of yet, but this is sure to become an area of
> focus once the more basic areas of the API have stabilized.
> We are, however, very much interested in hearing some thoughts about
> this. In particular, is the idea of a binding with a dynamic scope
> that reverts to the old value when we exit the scope a better one
> than the existing un-scoped lifetime of ThreadLocals, whose value
> persists until the next time it is set?

Yes, I'm sure it is. This is more or less basic structured
programming, isn't it? Besides, keeping scoped variables on the stack
means that when a continuation is saved and descheduled the bound
values of its scoped locals get saved along with everything else.

I have a rough design that I'd be happy to describe and attempt a
prototype implementation, but I'm wary that there may have been more
discussion that I missed. Also, I haven't looked at the actual
implementation of Loom so my approach might not be practical. I'd like
to try.

In brief, I think we want:

Nested scope: a value becomes visible once it is bound and that
binding ends when control passes through the end of the scope in which
the binding operation occurs.

Very fast reads, e.g. MyScopedVariable.get(). I think we can do this
with (typically) just a couple of load instructions and a conditional
branch, as long as the programmer keeps the number of scoped variables
small. I care about this property very much because the faster they
are the more use cases there will be for them.

Fast binding operations, but not as super-fast as simple reads because
some thread-local state will have to be updated or created.

Very small slowdown when mounting and dismounting continuations.

Security: it must be impossible for a class without access to the
declaration of a scoped variable to access it.

Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

More information about the loom-dev mailing list