RFR (XS) CR 8014233: java.lang.Thread should have @Contended on TLR fields

[Chris Hegarty]

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.