Improving ThreadLocalRandom (and related classes)

[Doug Lea]

On 01/09/13 05:55, Aleksey Shipilev wrote:
> On 01/08/2013 08:33 PM, Doug Lea wrote:
>> However, the actual ThreadLocalRandom object is padded to avoid
>> memory contention (which wouldn't be necessary or useful if already
>> embedded withing Thread).
>
> I'm tempted to disagree. While it is true most of the callers are
> accessing Thread in the context of currentThread(), and most of the
> Thread state is not updated, it can catastrophically break down once we
> cram in the heavily updated fields.

I think that adding @Contended to Thread will require
some empirically-guided judgement. It is true
that a bunch of Thread objects packed adjacently may
(even now) memory-contend. But it is not a likely
scenario because of garbage-collector policies. They
start off with per-thread roots, so will not often
relocate different Thread objects adjacently.
We use various Thread subclasses in j.u.c that add
some thread-local-like state, and I haven't ever
traced a performance glitch to memory contention
among them. But it would not be too hard to create
empirical experiments to check this more systematically.

-Doug