RFR (XS) CR 8014233: java.lang.Thread should be @Contended

[Aleksey Shipilev]

On 05/10/2013 05:27 PM, Aleksey Shipilev wrote:
> Although I just tried what Peter had suggested, and got even more
> boost on my microbenchmark. This counter-intuitive for me, since no
> memory layout differences could explain this in my tests. I will have
> to untangle this today, hold on.

Ok, I figured this out. That was a performance bug in JMH:
  http://mail.openjdk.java.net/pipermail/jmh-dev/2013-May/000045.html

Re-measuring my old test with that infra bug fixed yields no
*consistent* improvements for either @Contended on Thread, nor the TLR
state: the fields have minor chance to collide; although it happens
sometimes. As Doug noted, this is the lingering problem that can wake up
and kick you in the face.

So, with the renewed benchmark, which disturbs the other thread:
  http://cr.openjdk.java.net/~shade/8014233/threadbench.zip

ThreadLocalRandom.current().nextInt():
  baseline:              356 +-  3 ops/usec
  @Contended on Thread:  356 +-  2 ops/usec
  @Contended on TLR:     356 +-  1 ops/usec

ThreadLocalRandom.current().nextInt() *and* otherThread.getId():
  baseline:              106 +- 12 ops/usec
  @Contended on Thread:   99 +-  9 ops/usec
  @Contended on TLR:     323 +-  5 ops/usec

Here, the whooping 3x hit just because we accessed the ID of the other
thread, and disturbed the cache line containing the TLR state.
@Contended on Thread does not help much about this, because those fields
are densely packed.

The webrev for @Contended on TLR state is here:
  http://cr.openjdk.java.net/~shade/8014233/webrev.01/

I'd like to proceed with this one instead.

Thanks,
-Aleksey.