Improving ThreadLocalRandom (and related classes)

[Doug Lea]

On 01/08/13 11:07, Chris Hegarty wrote:
> Doug,
>
> I have no objection as such to adding certain fields to j.l.Thread to support
> faster ThreadLocalRandom. Maybe it would help to see how they are to be used?

One use that reminded me that I ought to take this issue
out of background and propose it was the the discussion
surrounding the possible us of ThreadLocalRandom with
HashMaps.

It would be great if the 99% of all the uses of Random
that could sensibly use ThreadLocalRandom did so.
Improving the incentives to use it wouldn't hurt.

>
> Given, 1 and 2 below ( I'm not sure about 3 ), would having a direct reference
> from j.l.Thread to ThreadLocalRandom (rather than using ThreadLocal) resolve
> these problems?

Yes, this is the Plan-B approach. It seems a little worse.
For completeness, I should have mentioned it:
By just keeping an initially-null pointer to a ThreadLocalRandom,
you can reduce impact on class Thread itself from 16 to 4/8 bytes
(depending on 32 vs 64bit pointers). However,
the actual ThreadLocalRandom object is padded to avoid
memory contention (which wouldn't be necessary or useful if
already embedded withing Thread).  It also adds (a tiny bit)
to preventable GC load to have a pointer in Thread that is
never collectable and must be scanned even if never used.

While the decision depends in part on the probability of use,
I can't think of a good reason to recommend this approach.


-Doug