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

[David Holmes]

Hi Aleksey,

What is the overall change in memory use for this set of changes ie what 
did we use pre TLR merging and what do we use now?

Thanks,
David

On 17/06/2013 7:00 PM, 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.
>