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

[Aleksey Shipilev]

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.