Looks good to me too. (Just out of curiosity, what happens with CMS, is 
it correctly reported/set, or does it have the same issue -- i am not suggesting 
fixing it given the EOL plans for CMS; just wondered. Hmm, I think in CMS we directly use the flag variable, so should probably report fine.)<br>
<br>
-- ramki<br><br><div class="gmail_quote">On Thu, Jan 24, 2013 at 3:01 PM, John Cuthbertson <span dir="ltr"><<a href="mailto:john.cuthbertson@oracle.com" target="_blank">john.cuthbertson@oracle.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi All,<br>
<br>
Can I have a couple of volunteers look over this small change? The webrev can be found at: <a href="http://cr.openjdk.java.net/%7Ejohnc/8006894/webrev.0/" target="_blank">http://cr.openjdk.java.net/~<u></u>johnc/8006894/webrev.0/</a><br>

<br>
Summary:<br>
When G1 calculates the number of marking threads based upon (the develop-only) G1MarkingOverheadPercent or (more usually) ParallelGCThreads, we weren't setting the value of ConcGCThreads. As a result the output of PrintFlagsFinal would always show a zero if ConcGCThreads wasn't specified on the command line:<br>

<br>
    uintx ConcGCThreads                             = 0               {product}<br>
<br>
This made it difficult for the performance team to analyze marking behavior and offer advice. With this change we now get the calculated number of marking threads:<br>
<br>
Using ParallelGCThreads (default: 4):<br>
<br>
    uintx ConcGCThreads                            := 1               {product}<br>
<br>
Using G1MarkingOverheadPercent (50):<br>
<br>
    uintx ConcGCThreads                            := 2               {product}<br>
<br>
Testing:<br>
Command line testing; specjvm98 and dacapo with a low IHOP value (marking threshold).<br>
<br>
Thanks,<br>
<br>
JohnC<br>
</blockquote></div><br>