RFR(XS): 8005875: G1: Kitchensink fails with ParallelGCThreads=0

Vitaly Davidovich vitalyd at gmail.com
Wed Jan 9 04:37:59 UTC 2013


Hi John,

What's the advantage of checking parallel marking thread count > 0 rather
than checking if parallel workers is not NULL? Is it clearer that way? I'm
thinking checking for NULL here (perhaps with a comment on when NULL can
happen) may be a bit more robust in case it can be null for some other
reason, even if parallel marking thread count is > 0.

Looks good though.

Thanks

Sent from my phone
On Jan 8, 2013 5:14 PM, "John Cuthbertson" <john.cuthbertson at oracle.com>
wrote:

> Hi Everyone,
>
> Can I please have a couple of volunteers look over the fix for this CR -
> the webrev can be found at: http://cr.openjdk.java.net/~**
> johnc/8005875/webrev.0/<http://cr.openjdk.java.net/~johnc/8005875/webrev.0/>
>
> Summary:
> One of the modules in the Kitchensink test generates a VM_PrintThreads vm
> operation. The JVM crashes when it tries to print out G1's concurrent
> marking worker threads when ParallelGCThreads=0 because the work gang has
> not been created. The fix is to add the same check that's used elsewhere in
> G1's concurrent marking.
>
> Testing:
> Kitchensink with ParallelGCThreads=0
>
> Thanks,
>
> JohnC
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20130108/6e7d9c67/attachment.htm>


More information about the hotspot-gc-dev mailing list