Thanks! I do need a sponsor. -Aleksey.
On 06/17/2013 04:52 PM, Chris Hegarty wrote: > 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.
