CRR (S): 7119027: G1: use atomics to update RS length / predict time of inc CSet
Bengt Rutisson
bengt.rutisson at oracle.com
Tue Dec 20 20:48:27 UTC 2011
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):
>
> http://cr.openjdk.java.net/~tonyp/7119027/webrev.0/
>
> 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