Improving ThreadLocalRandom (and related classes) (original) (raw)

Doug Lea dl at cs.oswego.edu
Tue Jan 8 12:05:28 UTC 2013

When we introduced ThreadLocalRandom, we conservatively implemented it to use an actual ThreadLocal. However, as it becomes more widely used, it is worth improving the implementation by housing ThreadLocalRandom state (and related bookkeeping) in class Thread itself. This would entail three fields (16 total bytes).

So I propose adding the following to class Thread:

// The following three initially uninitialized fields are exclusively // managed by class java.util.concurrent.ThreadLocalRandom. /** The current seed for a ThreadLocalRandom / long threadLocalRandomSeed; /* Probe hash value; nonzero if threadLocalRandomSeed initialized / int threadLocalRandomProbe; /* Secondary seed isolated from public ThreadLocalRandom sequence */ int threadLocalRandomSecondarySeed;

The reasons for doing it in this way are:

  1. Uniformly faster access to ThreadLocalRandom state. While ThreadLocal access is normally pretty fast already, this is not only faster, it does not degrade in cases where user programs create large numbers of ThreadLocals, which may (probabilistically) cause any given access to become slower.

  2. Smaller total footprint for any program using ThreadLocalRandom. Three fields require less space than boxing into a padded ThreadLocal object. As ThreadLocalRandom becomes widely used within JDK itself, this includes just about all programs.

  3. Further time/space savings for java.util.concurrent ForkJoinPool, ConcurrentHashMap, LongAdder, ConcurrentSkipList, and other classes that could use this form of the unified ThreadLocalRandom bookkeeping rather than their own special-purpose ThreadLocals as they now do.

Any objections? If not, I'd need the help of someone permitted to paste the above into class Thread, review, and and commit.

-Doug

More information about the core-libs-dev mailing list