RFR: 8069273: Decrease Hot Card Cache Lock contention

Claes Redestad claes.redestad at oracle.com
Tue Jan 27 15:48:37 UTC 2015


On 01/27/2015 02:56 PM, Thomas Schatzl wrote:
> Hi,
> On Tue, 2015-01-27 at 11:32 +0100, Claes Redestad wrote:
>> 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
>    it would be nice to add a test case that checks boundary values like
> that for this flag.

This was discovered by jtreg test
hotspot/test/gc/g1/TestShrinkAuxiliaryData00.java, but it seems the
reset_hot_cache was only called intermittently since this slipped
through JPRT testing one or two times before it crashed on me.

Perhaps the test could be improved to ensure it will reset the
G1HotCardCache at least once. Ok to file a new RFE to look at
possible improvements?

>> 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.
> It would be nice if G1HotCardCache::initialize() used the reset()
> method. Then the initialization code would not need to be duplicated.
> The problem are the asserts in the reset() method - either create a
> reset_int(), or weaken the asserts by adding a !
> Universe::fully_initialized() there.

Ok, broken out into reset_hot_cache_internal method:

New webrev: http://cr.openjdk.java.net/~redestad/8069273/webrev.05/
Incremental: http://cr.openjdk.java.net/~redestad/8069273/webrev.05.04.inc/

> Looks good otherwise.



> Thanks,
>    Thomas

More information about the hotspot-gc-dev mailing list