<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jun 5, 2013 at 5:12 PM, Jon Masamitsu <span dir="ltr"><<a href="mailto:jon.masamitsu@oracle.com" target="_blank">jon.masamitsu@oracle.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hiroshi,<br>
<br>
I've looked at the parallel initial mark changeset so far.  Looks good.<br>
Would you says that the FlexibleWorkerGang<br>
<br>
// Parallel initial mark task<br>
class CMSParInitialMarkTask: public CMSParMarkTask {<br>
  FlexibleWorkGang* _workers;<br>
<br>
is unused above just as it is unnecessary in the constructor for<br>
CMSParRemarkTask?<br></blockquote><div><br></div><div style>Yes, it is unused and unnecessary. I'll remove it.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<br>
I'll look at the second changeset in a bit.<span class=""><font color="#888888"><br>
<br>
Jon</font></span><div class=""><div class="h5"><br>
<br>
<br>
<br>
On 5/30/2013 10:56 AM, Hiroshi Yamauchi wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Thanks, Jon. Please let me know when you know more.<br>
<br>
On Wed, May 29, 2013 at 6:37 PM, Jon Masamitsu <<a href="mailto:jon.masamitsu@oracle.com" target="_blank">jon.masamitsu@oracle.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Hiroshi,<br>
<br>
I'm still reviewing the changes but so far this looks<br>
very promising.  I've patched you changes into a repository<br>
and started running a few tests.  I've turned on<br>
<br>
-XX:+<u></u>CMSParallelInitialMarkEnabled -XX:+CMSEdenChunksRecordAlways<br>
<br>
Thanks.<br>
<br>
Jon<br>
<br>
<br>
On 5/28/2013 5:24 PM, Hiroshi Yamauchi wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Hi,<br>
<br>
I'd like to have the following contributed if it makes sense.<br>
<br>
1) Here's a patch (against a recent revision of the hsx/hotspot-gc repo):<br>
<br>
    <a href="http://cr.openjdk.java.net/~hiroshi/webrevs/cmsparinitmark/webrev.00/" target="_blank">http://cr.openjdk.java.net/~<u></u>hiroshi/webrevs/<u></u>cmsparinitmark/webrev.00/</a><br>
<br>
that implements a parallel version of the initial mark phase of the<br>
CMS collector. It's relatively a straightforward parallelization of<br>
the existing single-threaded code. With the above patch, I see about<br>
~3-6x speedup in the initial mark pause times.<br>
<br>
2) Now, here's a related issue and a suggested fix/patch for it:<br>
<br>
I see that the initial mark and remark pause times sometimes spike<br>
with a large young generation. For example, under a 1 GB young gen / 3<br>
GB heap setting, they occasionally spike up to ~500 milliseconds from<br>
the normal < 100 ms range, on my machine. As far as I can tell, this<br>
happens when the eden is fairly occupied (> 700 MB full) and not<br>
sufficiently divided up and the parallelism decreases (at the worst<br>
case it becomes almost single-threaded.)<br>
<br>
Here's a suggested patch in a separate patch:<br>
<br>
    <a href="http://cr.openjdk.java.net/~hiroshi/webrevs/edenchunks/webrev.00/" target="_blank">http://cr.openjdk.java.net/~<u></u>hiroshi/webrevs/edenchunks/<u></u>webrev.00/</a><br>
<br>
that attempts to improve on this issue by implementing an alternative<br>
way of dividing up the eden into chunks for an increased parallelism<br>
(or better load balancing between the GC threads) for the young gen<br>
scan portion of the remark phase (and the now-parallelized initial<br>
mark phase.) It uses a CAS-based mechanism that samples the object<br>
boundaries in the eden space on the slow allocation code paths (eg. at<br>
the TLAB refill and large object allocation times) at all times.<br>
<br>
This approach is in contrast to the original mechanism that samples<br>
object boundaries in the eden space asynchronously during the preclean<br>
phase. I think the reason that the above issue happens is that when<br>
the young generation is large, a large portion of the eden space could<br>
get filled/allocated outside of the preclean phase (or a concurrent<br>
collection) and the object boundaries do not get sampled<br>
often/regularly enough. Also, it isn't very suited for the parallel<br>
initial mark because the initial mark phase isn't preceded by the<br>
preclean phase unlike the remark phase. According to the Dacapo<br>
benchmarks, this alternative sampling mechanism does not have<br>
noticeable runtime overhead despite it is engaged at all times.<br>
<br>
With this patch, I see that the (parallel) initial mark and remark<br>
pause times stay below 100 ms (no spikes) under the same setting.<br>
<br>
Both of these features/flags are disabled by default. You're welcome<br>
to handle the two patches separately.<br>
<br>
Thanks,<br>
Hiroshi<br>
</blockquote>
<br>
</blockquote></blockquote>
<br>
</div></div></blockquote></div><br></div></div>