CRR (S): 7119027: G1: use atomics to update RS length / predict time of inc CSet

Tony Printezis tony.printezis at
Tue Dec 20 21:51:51 UTC 2011


Thanks for the code review. Yes, I like the non-atomics version too.


On 12/20/2011 03:48 PM, Bengt Rutisson wrote:
> Tony,
> Looks good. I like that it was possible to avoid atomic updates.
> Bengt
> On 2011-12-20 18:52, Tony Printezis wrote:
>> Hi all,
>> I'd like a couple of code reviews for this small change that resolves 
>> the race that we identified a few weeks ago (and which we already 
>> guard against in the code):
>> Instead of using atomics I decided to take an alternative approach to 
>> eliminate the race which as described in the CR:
>> "The final fix is somewhat different to what I had originally planned 
>> and does not use atomics. The observation is that only two threads 
>> can update the fields in question: a mutator thread that retires a 
>> region before allocating a new one (and it has to take the Heap_lock 
>> in order to do so - so those updates are serialized anyway) and a 
>> concurrent refinement thread that samples the RSets in the inc CSet. 
>> What we'll do is to accumulate the updates from each thread on 
>> separate fields and we'll just combine them at the start of a GC."
>> Thanks,
>> Tony

More information about the hotspot-gc-dev mailing list