RFR: 8069273: Decrease Hot Card Cache Lock contention

[Claes Redestad]

Hi again,

new webrev: http://cr.openjdk.java.net/~redestad/8069273/webrev.04/

This version fixes a crash issue in G1HotCardCache::reset_hot_cache when
G1ConcRSLogCacheSize=0

G1HotCardCache::hot_cache_is_empty was broken in the same way, but
since it was unused I've opted to remove it rather than fix it.

/Claes

On 01/23/2015 04:34 PM, Claes Redestad wrote:
> Hi all,
>
> updated webrev: http://cr.openjdk.java.net/~redestad/8069273/webrev.02/
>
> Changes: after some helpful suggestions offline from Stefan Karlsson I've
> replaced the cmpxchg loop on _hot_cache_idx with use of Atomic::add.
> This is arguably cleaner and also improves performance dramatically on
> architectures with support for atomic adds.
>
> /Claes
>
> On 01/22/2015 05:27 PM, Claes Redestad wrote:
>> Hi all,
>>
>> please review this patch which replaces the use of mutex-based 
>> locking in
>> G1HotCardCache with a non-blockingCAS loop.
>>
>> webrev: http://cr.openjdk.java.net/~redestad/8069273/webrev.01/
>> bug: https://bugs.openjdk.java.net/browse/JDK-8069273
>>
>> This improves performance in a microbenchmark designed to indirectly
>> stress the "card is hot" branch of G1HotCardCache::insert[1]. More 
>> thorough
>> performance testing is in progress.
>>
>> An initial prototype did not isolate the _hot_cache_idx, which 
>> introduced
>> catastrophic levels of false sharing on nearby fields, ending up in
>> odd results and no real effect on total throughput. The padding 
>> introduced
>> around_hot_cache_idx and _hot_cache_par_claimed_idx was necessary to
>> address this.
>>
>> Testing: JPRT -testset hotspot
>>
>> /Claes
>>
>> [1] http://cr.openjdk.java.net/~redestad/8069273/G1HotCardBench.java
>