RFR (XS): 7114303: G1: assert(_g1->mark_in_progress()) failed: shouldn't be here otherwise

John Cuthbertson john.cuthbertson at oracle.com
Tue Nov 22 20:45:46 UTC 2011


Hi Everyone,

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/

Summary:
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.

Thanks,

JohnC



More information about the hotspot-gc-dev mailing list