RFR (XS) CR 8014233: java.lang.Thread should have @Contended on TLR fields
Aleksey Shipilev
aleksey.shipilev at oracle.com
Mon Jun 17 09:00:37 UTC 2013
Hi,
This is the respin of the RFE filed a month ago:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-May/016754.html
The webrev is here:
http://cr.openjdk.java.net/~shade/8014233/webrev.02/
Testing:
- JPRT build passes
- Linux x86_64/release passes jdk/java/lang jtreg
- vm.quick.testlist, vm.quick-gc.testlist on selected platforms
- microbenchmarks, see below
The rationale follows.
After we merged ThreadLocalRandom state in the thread, we are now
missing the padding to prevent false sharing on those heavily-updated
fields. While the Thread is already large enough to separate two TLR
states for two distinct threads, we can still get the false sharing with
other thread fields.
There is the benchmark showcasing this:
http://cr.openjdk.java.net/~shade/8014233/threadbench.zip
There are two test cases: first one is only calling its own TLR with
nextInt() and then the current thread's ID, another test calls *another*
thread ID, thus inducing the false sharing against another thread's TLR
state.
On my 2x2 i5 laptop, running Linux x86_64:
same: 355 +- 1 ops/usec
other: 100 +- 5 ops/usec
Note the decrease in throughput because of the false sharing.
With the patch:
same: 359 +- 1 ops/usec
other: 356 +- 1 ops/usec
Note the performance is back. We want to evade these spurious decreases
in performance, due to either unlucky memory layout, or the user code
(un)intentionally ruining the cache line locality for the updater thread.
Thanks,
-Aleksey.
More information about the core-libs-dev
mailing list