JDK-7119027 : G1: use atomics to update RS length / predict time of inc CSet
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: hs23
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2011-12-07
  • Updated: 2013-09-18
  • Resolved: 2012-03-29
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7 JDK 8 Other
7u4Fixed 8Fixed hs23Fixed
Related Reports
Relates :  
JDK-7118202 - G1: eden size unnecessarily drops to the minimum
Description
7118202 (G1: eden size unnecessarily drops to the minimum) has a description of a race that causes the RSet length of the inc CSet to become inconsistent (and in some cases very large). As part of that CR we put defensive code to detect and deal with this issue. This CR will fix the race "properly".

The race happens when a concurrent refinement thread updates the inc CSet data concurrently with a mutator thread that retires a mutator alloc region. To avoid taking more locks we should use atomic operations to update the inc CSet RSet lengths. In fact, the inc CSet elapsed time is also prone to get corrupted due to the same race so we should also atomically update that field too.
Comments
EVALUATION http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/67fdcb391461
22-03-2012
EVALUATION http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/67fdcb391461
21-12-2011
SUGGESTED FIX 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. Apart from the fact that they are inherently more expensive, avoiding atomics here is a good idea given that we'd need to use a retry-until-CAS-succeeds scheme to update the double field and repeated retries might impose unnecessary latency on the allocating mutator thread (which might be holding up all the other mutator threads from allocating).
20-12-2011
SUGGESTED FIX Use atomics to update the RSet length and predicted elapsed time fields of the inc CSet.
07-12-2011
EVALUATION See Description and Evaluation in 7118202.
07-12-2011