RFR: 8069273: Decrease Hot Card Cache Lock contention
thomas.schatzl at oracle.com
Thu Jan 29 12:22:29 UTC 2015
On Tue, 2015-01-27 at 16:48 +0100, Claes Redestad wrote:
> 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?
I recommend an extra specific test that checks the G1ConcRSLogCacheSize
option. TestShrinkAuxiliaryData* has a different purpose than checking
validity of input values.
> >> 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.
More information about the hotspot-gc-dev