RFR (XS): 7114303: G1: assert(_g1->mark_in_progress()) failed: shouldn't be here otherwise
john.cuthbertson at oracle.com
Tue Nov 22 12:45:46 PST 2011
Can I have a couple of volunteers review this small change? The webrev
can be found at: http://cr.openjdk.java.net/~johnc/7114303/webrev.0/
There is a race between the concurrent mark thread updating the mark in
progress flag and it being read by the VM thread during an evacuation
pause. This is because, at the time the concurrent mark thread updates
the flag, it is not part of the suspendible thread set and so is not
blocked. The solution is to have the concurrent mark thread join the STS
just before updating the flag.
The race was confirmed by inserting a small delay immediately before
calling G1CollectorPolicy::record_satb_drain_time(). The delay increased
failure rate to 1/5 for a 20ms delay and 4/5 for a 50ms delay.
Testing: a few thousand iterations of the failing test case with a JVM
that included both fix and delay.
More information about the hotspot-gc-dev