RFR(S): 8004816: G1: Kitchensink failures after marking stack changes

[Jon Masamitsu]

John,

Your fix looks good.

A small suggestion.  Instead of clear_marking_state() how
about reinitialize_marking_state() or reset_marking_state()?
When I went to look at what "clear_marking_state"
did, I expected it to simply set a variable but it does
more.  I thought that "reinitialize" or "reset" would
warn the reader that more was happening.
If this is in keeping with G1 naming
convention, it's fine to leave it.

Jon



On 12/13/12 09:45, John Cuthbertson wrote:
> Hi Everyone,
>
> Can I have a couple of volunteers review the fix for this CR? The 
> webrev can be found at: 
> http://cr.openjdk.java.net/~johnc/8004816/webrev.0/
>
> Summary:
> The reduced mark stack size that came in as part of the changes for 
> 8000244 exposed this issue. If the marking stack overflowed as a 
> result of pushes from the serial reference processing closures, the 
> marking stack overflow flag was not cleared. When marking eventually 
> completed, after the subsequent restarting, the still set overflow 
> flag was detected and resulted in a guarantee failure. I also 
> discovered that the actual marking state was not correctly cleared for 
> restarting for such an overflow and, as a result, some referent 
> objects might have been skipped by marking (those that are reachable 
> from the objects we failed to push as a result of the overflow).
>
> Normally this is not a problem as the serial reference processing code 
> is executed infrequently - except on systems with one or two cpus. The 
> parallel reference processing closures reset the marking state 
> correctly in the event of an overflow in the global marking stack.
>
> Testing:
> Kitchensink on 1 and 2 cpu systems with a very low mark stack size and 
> marking verification.
>
> Thanks,
>
> JohnC