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.


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

> 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.java.net/pipermail/hotspot-gc-dev/attachments/20130108/6e7d9c67/attachment.htm>

More information about the hotspot-gc-dev mailing list