Looks fine to me Aleksey. Let me know if you need a sponsor.
-Chris. On 17/06/2013 10:00, Aleksey Shipilev wrote:
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.
