Scoped variables

[dean.long at oracle.com]

Hi Andrew,

On 8/7/19 9:45 AM, Andrew Haley wrote:
> 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.
>

Please do.  I did some investigation a while back, but I had a different 
focus.  I was mostly looking into guarantees that the binding is removed 
when we exit the scope, not  performance (I used a WeakHashMap).

dl

> 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.
>