Scoped variables

[David Lloyd]

On Tue, Dec 4, 2018 at 3:41 PM <dean.long at oracle.com> wrote:
> On 12/4/18 12:32 PM, Doug Lea wrote:
> > On 12/4/18 12:12 PM, Andrew Haley wrote:
> >> Exactly, yes. The problem is that the current TheadLocal code is very
> >> complex, and if we restrict ourselves to a simple get() we can do
> >> better.
> > Could you explain? Of the possibilities I'm aware of that might be cheaper:
> >
> > * The cheapest version is to access a field of current Thread/Fiber, as
> > is possible with Threads by defining Thread subclasses.
> >
> > * Close behind is to have an index associated with each Thread/Fiber
> > that users could then use to access data in a separate array (or
> > whatever) that they otherwise manage themselves.
>
> I suppose we could also invert the above and having an index associated with
> each thread local to access an array in each fiber.  We could allocate
> the index
> for the life of the VM if we had a flavor of "permanent" thread local.
> However, recycling indexes and resizing arrays when a non-permanent
> thread local becomes collectable by the GC doesn't sound trivial to me.

It's a tradeoff, however an array indexed by thread ID would almost
certainly be subject to false sharing, so that's no panacea either.

> > * Of variants hinted at by John Rose, the only potentially fast kind I
> > know would be to stack-allocate at initial frames of a Thread/Fiber, and
> > use a new form of VarHandle that can be passed in calls or even somehow
> > implicitly accessed via some form of "display" so they can be accessed
> > by children (in the same or a nested Thread/Fiber)
> > (see https://en.wikipedia.org/wiki/Call_stack#Lexically_nested_routines)
>
> If I understand this correctly, we wouldn't have to map from a shared
> key object
> to something stack-local, because we would only allow access through
> something that is already stack-local.  However, I don't see how the inner
> callee lookup could be directly associated with the outer binding. If
> each frame
> was passed a hidden list of bound VarHandles, then it seems like lookup
> would
> still need to search that list, though the list is probably short.

Passing hidden values is a good use case for static thread locals
(assuming they would utilize just a couple of lookups).  In fact
static thread locals can be used to implement probably most of the
suggested mechanisms...

-- 
- DML