Scoped variables

[Florian Weimer]

* Doug Lea:

> An alternative is to use processorId as an index of some kind. Note that
> usages must be (and already are) thread-safe because a thread may move
> to a different core after obtaining ID, so it mostly acts as a hint.
>
> There are a few contexts where processorId might be the only reasonable
> option, but in current usages it is noticeably worse than current
> approach, because:
>
> * The underlying instructions (variants of CPUID on x86, plus decoding
> to turn results into indices) tend to be slow. They vary across Intel
> and AMD machines I tested on but is usually not reliably faster than a
> conditional atomic instruction (CompareAndSet etc) that we are trying to
> avoid calling more than once.

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

> * In part because of GC-based pause/resumes that lead to rescheduling,
> threads tend to frequently move across cores (at least on Linux test
> machines).

Using all cores is beneficial for thermal management on some CPUs.

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 t hat it stays within array bounds.

Thanks,
Florian