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.
