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

[Vitaly Davidovich]

Hi John,

Thanks for the response.  Yeah, I figured it's the same thing since it's
not null iff # of workers > 0.  However, if this relationship is ever
broken or perhaps the gang can be set to null at some point even if workers
> 0, then this code will segv again.  Hence I thought a null guard is a bit
better, but it was just a side comment - code looks fine as is.

Thanks

Sent from my phone
On Jan 9, 2013 7:41 PM, "John Cuthbertson" <john.cuthbertson at oracle.com>
wrote:

>  Hi Vitaly,
>
> Thanks for looking over the changes. AFAICT checking if _parallel_workers
> is not null is equivalent to checking that the number of parallel marking
> threads is > 0. I went with the latter check as other references to the
> parallel workers work gang are guarded by it. I'm not sure why the code was
> originally written that way but my guess is that, when originally written,
> the marking threads (like the concurrent refinement threads currently) were
> not in a work gang.
>
> Thanks,
>
> JohnC
>
> On 1/8/2013 8:37 PM, Vitaly Davidovich wrote:
>
> 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/
>>
>> 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/20130109/e75b0ffd/attachment.htm>