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

Doug Lea 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.

-Doug

More information about the core-libs-dev mailing list