[concurrency-interest] threadLocalRandomProbe

Doug Lea dl at cs.oswego.edu
Sat Aug 22 08:56:53 EDT 2015

On 08/21/2015 01:56 PM, Ben Manes wrote:
> Are there any plans on providing a handle or abstraction for
> threadLocalRandomProbe (as a thread-specific hash, e.g. Striped64)? It is quite
> useful for striping [1] and back-off arenas [2, 3]. It would be nice to not lose
> this optimization when transitioning away from Unsafe.

This is among a few cases where Unsafe is currently the only way
to access a jdk-private field that wouldn't be "unsafe" to export
(at least read-only), but no one has come up with a good way to expose.
In fact, the main reason they use Unsafe internally is that people
didn't want to expose fringe methods with only jdk-internal known
usages in commonly used classes; in particular class Thread.
Other examples include park/unpark mechanics for maintaining the
"parkBlocker" field used for monitoring and debugging.

I think Paul Sandoz (currently on vacation) has had some thoughts
on these, but I don't think there are any plans about them. And for
jdk9 at least, within-jdk use of Unsafe is allowed.

The case of threadLocalRandomProbe is hard to accommodate because
it is part of a particular algorithm: When you have collisions among
threads in a hash-table with size bounded by #cores, then upon
collision, move the hash code. This a dynamic analog of "perfect
hashing" that works extremely well in Striped64 and elsewhere.
Even though they use different tables, a collision in one implies
collisions in others, so any usage can move the code with generally
positive effect on other usages, but only if they follow that rule.
So while we could expose read-only, it would be a bad idea to export
the update method.


More information about the Concurrency-interest mailing list