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

Aleksey Shipilev aleksey.shipilev at oracle.com
Fri May 10 18:10:45 UTC 2013

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.

More information about the core-libs-dev mailing list