Scoped variables

[Florian Weimer]

* Doug Lea:

>> We have a faster implementation coming down the pipe, based on the rseq
>> system call and a per-thread area where the kernel stores the current
>> processor ID.  Details are still a bit sketchy.  If you think this could
>> be useful to OpenJDK, we can still make changes to the glibc ABI to make
>> it easier to consume from JIT code, for example.  (The userspace ABI is
>> fixed, though.)
>
> This also suggests some new API to efficiently access (or interoperate
> with)  pthreads TLS? Maybe this could even be the primary form of
> "static thread-locals" Andrew Haley has discussed.

The current plan is to provide what is effectively an initial-exec ELF
TLS variable with the processor ID, updated by the kernel.  The
initial-exec aspect could be made part of the ABI; it would mean that
the offset between the thread pointer and the variable is constant
across all threads in a process (but it could differ among invocations).
If that's not good enough and you need a constant offset from the thread
pointer, that could be negotiated as well, but it would be harder to get
consensus for that, considering that rseq is a new interface, and the
initial-exec model provides more flexibility to make future changes.

rseq offers some other features, of course, the processor ID is just one
aspect of it (but one that would be easy to use).

>> One thing to consider is that due to CPU hotplug (probably as the result
>> of VM migration) and process migration, the CPU count can go up.  If you
>> use the processor ID as an array index, you will have to mask it or
>> otherwise ensure that it stays within array bounds.

> Yes. It will make the getProcessorId() method interesting to specify.
> Probably Runtime.getAvailableProcessors() would also need some work.

We already fake a processor count of two if we can't determine the real
count, to prevent Hotspot from activating uniprocessor
optimizations. 8-/

Thanks,
Florian