Scoped variables

[Doug Lea]

Sitting on this a day, I'm more in favor of adding getProcessorId(),
probably as a method of Runtime, even though it doesn't help with some
cases we thought it might.


On 12/17/18 6:39 AM, Florian Weimer wrote:
> * 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.

And not a very good hint in existing usages: Contention is a function of
what threads do, not necessarily the cores they run on. And if updating
data structures when they switch cores has some time/space cost, it is
usually best not to rely on processor IDs, even if getProcessorId were
cheaper than it is.

But there are other applications (for example massively contended locks
for large systems, of the kind Dave Dice et al have worked on) where
there is little cost after initial setup, and so this should often be a
good choice. We haven't done anything for these usages in
java.util.concurrent in part because we don't have underlying support,
including method getProcessorId.

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

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

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

-Doug