<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jun 5, 2013 at 9:07 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hiroshi,<br>
<br>
For the sampling change.<br>
<br>
I appreciate that you allow for reverting to the old behavior of<br>
sampling during precleaning but am curious about whether<br>
you've seen an occasion where it was preferable.<br></blockquote><div><br></div><div style>I assume you are referring to an occasion where the old behavior was preferable than the new behavior. No, I haven't seen such a case. As far as I can tell, there's no noticeable runtime overhead due to the new way of sampling, and I haven't seen a case where the remark pause time was better with the old behavior. The new behavior is disabled by default just for conservatism. If it's preferred to adopt the new behavior without a flag, there's no problem with me.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<a href="http://cr.openjdk.java.net/~hiroshi/webrevs/edenchunks/webrev.00/src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp.frames.html" target="_blank">http://cr.openjdk.java.net/~<u></u>hiroshi/webrevs/edenchunks/<u></u>webrev.00/src/share/vm/gc_<u></u>implementation/<u></u>concurrentMarkSweep/<u></u>concurrentMarkSweepGeneration.<u></u>hpp.frames.html</a><br>

<br>
 739   // This is meant to be a boolean flag, but jbyte for CAS.<br>
 740   jbyte      _eden_chunk_sampling_active;<br>
<br>
Other than the card table I'm used to seeing the atomic operations<br>
on word sized variables.     Would jint work as well and be simpler to<br>
think about?<br></blockquote><div><br></div><div style>Sure. jint would be fine, too.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
Maybe more later.<div class="im HOEnZb"><br>
<br>
Jon<br>
<br>
<br>
<br>
On 5/28/2013 5:24 PM, Hiroshi Yamauchi wrote:<br>
</div><div class="HOEnZb"><div class="h5"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc 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>
</div></div></blockquote></div><br></div></div>