RFR (XS): 7114303: G1: assert(_g1->mark_in_progress()) failed: shouldn't be here otherwise
Bengt Rutisson
bengt.rutisson at oracle.com
Wed Nov 23 07:44:12 UTC 2011
Hi John,
Looks good to me too.
It seems like the method "void record_satb_drain_processed_buffers(int
processed_buffers)" in g1CollectorPolicy.hpp is dead code. I found it
since it contains the same assert that your CR reported.
Any chance of removing that method as well as part of your change?
Bengt
On 2011-11-22 21:45, John Cuthbertson wrote:
> 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