Improving ThreadLocalRandom (and related classes)
dl at cs.oswego.edu
Wed Jan 9 12:07:59 UTC 2013
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.
More information about the core-libs-dev