Scoped variables

Alan Bateman Alan.Bateman at
Tue Dec 4 15:10:33 UTC 2018

On 04/12/2018 05:46, David Holmes wrote:
> RTSJ Scoped Memory is somewhat of a different beast to general 
> "context"-local variables - where a context may be a thread, a fiber, 
> a session, etc.
> RTSJ Scoped Memory actually allocated the objects into a memory region 
> that had a lifetime that was connected to the active execution of the 
> current thread. They were intended to act more like stack allocated 
> Java objects, and came with significant restrictions on assignment and 
> use as shorter-lived instances could not be assigned to fields of 
> longer lived instances, nor returned up the call stack beyond the 
> start of the allocation scope. (And a complex tree-based memory region 
> management scheme, that allowed controlled sharing across threads, 
> made things even more complex!)
> "context"-locals on the other hand don't deal with allocation at all, 
> they are simply "maps" from the current-"context" to a named variable.
> I'm not sure what Loom "Scoped variables" are intended to be exactly.
If I understand RTSJ scoped memory correctly then it may have some 
similarities to the structured concurrency concepts that we are also 
exploring, esp. with nested scopes. We also want to explore using scoped 
locals within these fiber scopes.

As regards the intentions then we have been surveying usages of thread 
locals. We talked briefly about this at the reason kick off meeting [1]. 
Part of the motivation is to see how far we can get without introducing 
"fiber locals". Another part is recognizing that a many existing usages 
of thread locals are because there isn't anything better. It's not hard 
to find cases where a thread local is used as an approximation of a 
processor local. It's also not hard to find cases where thread locals 
are used to make context available to callees further down in the stack 
- the typical pattern is create/set a thread local, do some task that 
will access the local further down in the stack, and then remove/clear 
the local in a finally block. It's these cases where we want to explore 
with frame/scoped locals.



More information about the loom-dev mailing list