RFR: 8069273: Decrease Hot Card Cache Lock contention

Mikael Gerdin mikael.gerdin at oracle.com
Tue Jan 27 13:56:53 UTC 2015


Hi Claes,

On 2015-01-27 11:32, Claes Redestad wrote:
> Hi again,
>
> new webrev: http://cr.openjdk.java.net/~redestad/8069273/webrev.04/

The change looks good to me.

/Mikael

>
> 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
>>
>



More information about the hotspot-gc-dev mailing list