<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hi Ramki,<br>
<br>
CMS does do the correct thing. Here's the code:<br>
<br>
// Support for multi-threaded concurrent phases<br>
if (CMSConcurrentMTEnabled) {<br>
if (FLAG_IS_DEFAULT(ConcGCThreads)) {<br>
// just for now<br>
FLAG_SET_DEFAULT(ConcGCThreads, (ParallelGCThreads + 3)/4);<br>
}<br>
if (ConcGCThreads > 1) {<br>
_conc_workers = new YieldingFlexibleWorkGang("Parallel CMS
Threads",<br>
ConcGCThreads, true);<br>
if (_conc_workers == NULL) {<br>
warning("GC/CMS: _conc_workers allocation failure: "<br>
"forcing -CMSConcurrentMTEnabled");<br>
CMSConcurrentMTEnabled = false;<br>
} else {<br>
_conc_workers->initialize_workers();<br>
}<br>
} else {<br>
CMSConcurrentMTEnabled = false;<br>
}<br>
}<br>
<br>
I guess an argument could be made that it should only set
ConcGCThreads if the value is 0. If a non-zero default was given
then we override that default. Also I think we should set
ConcGCThreads using FLAG_SET_ERGO. Using FLAG_SET_ERGO when we're
ergonomically turning off CMSConcurrentMTEnabled (because the # of
threads is 1 or the allocation of work gang fails).<br>
<br>
But the main answer is I see a non-zero value for ConcGCThreads in
the PrintFlagsFinal output:<br>
<br>
uintx ConcGCThreads =
2 {product} <br>
<br>
JohnC<br>
<br>
<br>
<div class="moz-cite-prefix">On 1/24/2013 5:33 PM, John Cuthbertson
wrote:<br>
</div>
<blockquote cite="mid:5101E0FD.1030700@oracle.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
Hi Ramki,<br>
<br>
Thanks for looking at the change. I'll generate the output for CMS
later tonight. From conversations with the perf team I believe CMS
is OK in this regard.<br>
<br>
JohnC<br>
<br>
<div class="moz-cite-prefix">On 1/24/2013 5:29 PM, Srinivas
Ramakrishna wrote:<br>
</div>
<blockquote
cite="mid:CABzyjy=OgWZQQFc5rMJRqoJ+JZnZ6Vm6uykN1P3OKZ=KCZyoeA@mail.gmail.com"
type="cite">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 moz-do-not-send="true"
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
moz-do-not-send="true"
href="http://cr.openjdk.java.net/%7Ejohnc/8006894/webrev.0/"
target="_blank">http://cr.openjdk.java.net/~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>
</blockquote>
<br>
</blockquote>
<br>
</body>
</html>