RFR (XS) CR 8014233: java.lang.Thread should have @Contended on TLR fields
aleksey.shipilev at oracle.com
Mon Jun 17 13:28:11 UTC 2013
Thanks! I do need a sponsor.
On 06/17/2013 04:52 PM, Chris Hegarty wrote:
> 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