Improving ThreadLocalRandom (and related classes)

[Aleksey Shipilev]

On 01/09/2013 04:07 PM, Doug Lea wrote:
> 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.

Fair enough. Let's go the optimistic route without @Contended then.
Meanwhile, we can arrange some experiments to have some calamity.

-Aleksey.