RFR(XXS): 8006894: G1: Number of marking threads missing from PrintFlagsFinal output

[Srinivas Ramakrishna]

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.)

-- ramki

On Thu, Jan 24, 2013 at 3:01 PM, John Cuthbertson <
john.cuthbertson at oracle.com> wrote:

> Hi All,
>
> Can I have a couple of volunteers look over this small change? The webrev
> can be found at: http://cr.openjdk.java.net/~**johnc/8006894/webrev.0/<http://cr.openjdk.java.net/%7Ejohnc/8006894/webrev.0/>
>
> Summary:
> 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:
>
>     uintx ConcGCThreads                             = 0
> {product}
>
> 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:
>
> Using ParallelGCThreads (default: 4):
>
>     uintx ConcGCThreads                            := 1
> {product}
>
> Using G1MarkingOverheadPercent (50):
>
>     uintx ConcGCThreads                            := 2
> {product}
>
> Testing:
> Command line testing; specjvm98 and dacapo with a low IHOP value (marking
> threshold).
>
> Thanks,
>
> JohnC
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20130124/603c0631/attachment.htm>