<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
<br>
On 10/27/2011 10:28 PM, <a class="moz-txt-link-abbreviated" href="mailto:poonam.bajaj@oracle.com">poonam.bajaj@oracle.com</a> wrote:
<blockquote cite="mid:4EAA3D96.1080309@oracle.com" type="cite">
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
...<br>
<br>
On 10/28/2011 12:11 AM, Jon Masamitsu wrote:
<blockquote cite="mid:4EA9A5EB.1030707@oracle.com" type="cite">
<meta content="text/html; charset=UTF-8"
http-equiv="Content-Type">
<br>
<br>
On 10/27/11 02:49, <a moz-do-not-send="true"
class="moz-txt-link-abbreviated"
href="mailto:poonam.bajaj@oracle.com">poonam.bajaj@oracle.com</a>
wrote:
<blockquote cite="mid:4EA92924.1050000@oracle.com" type="cite">
<meta content="text/html; charset=UTF-8"
http-equiv="Content-Type">
...<br>
- concurrentMarkSweepGeneration.cpp, line 5551<br>
<br>
Here, flag UseDynamicNumberOfGCThreads can be checked to make
the decision if we need to use 'active_workers', the way you
have done it in collectionSetChooser.cpp at line 258<br>
</blockquote>
<br>
What I meant to say was that at 5551 I wanted to use whatever
value of<br>
active_workers that was calculated when calc_active_workers()
was last<br>
called. That would likely be the value at the last young GC or
at the<br>
initial-mark. I had at one point thought there was a dependency
between<br>
the number of GC threads used in a young collection and the
number used<br>
in the remark. I've been told that is not the case but have not
proven<br>
that to myself and since lots of testing has already been done
with this<br>
code, I left it unchanged with a note to myself to look at it
again.<br>
</blockquote>
</blockquote>
<br>
If there is a dependency, it is merely an artifact of the
implementation<br>
and should, in principle not be there -- after all the optimal
parallelism for<br>
scavenge could well be different from what's optimal for parallel
remark.<br>
Thus, it makes sense to control the two independently. Leaving it as
is<br>
for now is quite fine, with any remaining dependencies to be removed
at<br>
a later time when more policy/tuning is done.<br>
<br>
<blockquote cite="mid:4EAA3D96.1080309@oracle.com" type="cite">
<blockquote cite="mid:4EA9A5EB.1030707@oracle.com" type="cite"> <br>
Did I understand your comment?<br>
</blockquote>
<br>
Yes.<br>
<br>
So, if the active_workers was not set then we will not calculate
the<br>
active_workers with calc_active_workers() again and instead <br>
use ParallelGCThreads.<br>
</blockquote>
<br>
Yes.<br>
<br>
<blockquote cite="mid:4EAA3D96.1080309@oracle.com" type="cite"> <br>
Where in the code are the active_workers set for initial-marking <br>
phase?<br>
</blockquote>
<br>
Unfortunately, CMS initial mark is currently single-threaded, so
it's likely there isn't any code<br>
to change (to set #active workers) there.<br>
<br>
<blockquote cite="mid:4EAA3D96.1080309@oracle.com" type="cite"> <br>
<blockquote cite="mid:4EA9A5EB.1030707@oracle.com" type="cite">
<blockquote cite="mid:4EA92924.1050000@oracle.com" type="cite">
<br>
- concurrentMarkSweepGeneration.cpp at line 5899<br>
<br>
same as above comment<br>
</blockquote>
<br>
My intent was to set a number of GC workers for a <br>
collection (minor or full or initial-mark or remark)<br>
so didn't want to change within the collection (Reference<br>
processing being done as part of the remark) so that's<br>
why I'm here just using what has previously been <br>
calculated.<br>
<br>
</blockquote>
Ok.<br>
</blockquote>
<br>
Once again, as has been discussed in perhaps a different context,<br>
there is no reason that the optimal # for parallel reference
processing<br>
should be identical to that used for either parallel remark or<br>
for scavenge. Thus (in general) it is possible that optimal settings<br>
for all three could be quite different. (It could well be that they
turn out<br>
to be the same, but we should not assume for the purposes of an<br>
initial design that they should be the same.) Once again, lacking
any good policy/tuning<br>
at the moment, it is fine to leave the code as is in Jon's webrev,
with<br>
those dependencies removed at a later point when
optimal/policy/tuning<br>
is done.<br>
<br>
<blockquote cite="mid:4EAA3D96.1080309@oracle.com" type="cite"> <br>
...<br>
<blockquote cite="mid:4EA9A5EB.1030707@oracle.com" type="cite">
<blockquote cite="mid:4EA92924.1050000@oracle.com" type="cite">
<blockquote cite="mid:4EA893B9.7070905@oracle.com" type="cite">
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://cr.openjdk.java.net/%7Ejmasa/6593758/webrev.00/">http://cr.openjdk.java.net/~jmasa/6593758/webrev.00/</a>
<br>
<br>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<br>
-- ramki<br>
</body>
</html>