RFR (XS) CR 8014233: java.lang.Thread should have @Contended on TLR fields
chris.hegarty at oracle.com
Mon Jun 17 12:52:04 UTC 2013
Looks fine to me Aleksey.
Let me know if you need a sponsor.
On 17/06/2013 10:00, Aleksey Shipilev wrote:
> This is the respin of the RFE filed a month ago:
> The webrev is here:
> - 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:
> 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
> 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.
More information about the core-libs-dev