CMS parallel initial mark
jon.masamitsu at oracle.com
Thu Jun 6 04:07:31 UTC 2013
For the sampling change.
I appreciate that you allow for reverting to the old behavior of
sampling during precleaning but am curious about whether
you've seen an occasion where it was preferable.
739 // This is meant to be a boolean flag, but jbyte for CAS.
740 jbyte _eden_chunk_sampling_active;
Other than the card table I'm used to seeing the atomic operations
on word sized variables. Would jint work as well and be simpler to
Maybe more later.
On 5/28/2013 5:24 PM, Hiroshi Yamauchi wrote:
> I'd like to have the following contributed if it makes sense.
> 1) Here's a patch (against a recent revision of the hsx/hotspot-gc repo):
> that implements a parallel version of the initial mark phase of the
> CMS collector. It's relatively a straightforward parallelization of
> the existing single-threaded code. With the above patch, I see about
> ~3-6x speedup in the initial mark pause times.
> 2) Now, here's a related issue and a suggested fix/patch for it:
> I see that the initial mark and remark pause times sometimes spike
> with a large young generation. For example, under a 1 GB young gen / 3
> GB heap setting, they occasionally spike up to ~500 milliseconds from
> the normal < 100 ms range, on my machine. As far as I can tell, this
> happens when the eden is fairly occupied (> 700 MB full) and not
> sufficiently divided up and the parallelism decreases (at the worst
> case it becomes almost single-threaded.)
> Here's a suggested patch in a separate patch:
> that attempts to improve on this issue by implementing an alternative
> way of dividing up the eden into chunks for an increased parallelism
> (or better load balancing between the GC threads) for the young gen
> scan portion of the remark phase (and the now-parallelized initial
> mark phase.) It uses a CAS-based mechanism that samples the object
> boundaries in the eden space on the slow allocation code paths (eg. at
> the TLAB refill and large object allocation times) at all times.
> This approach is in contrast to the original mechanism that samples
> object boundaries in the eden space asynchronously during the preclean
> phase. I think the reason that the above issue happens is that when
> the young generation is large, a large portion of the eden space could
> get filled/allocated outside of the preclean phase (or a concurrent
> collection) and the object boundaries do not get sampled
> often/regularly enough. Also, it isn't very suited for the parallel
> initial mark because the initial mark phase isn't preceded by the
> preclean phase unlike the remark phase. According to the Dacapo
> benchmarks, this alternative sampling mechanism does not have
> noticeable runtime overhead despite it is engaged at all times.
> With this patch, I see that the (parallel) initial mark and remark
> pause times stay below 100 ms (no spikes) under the same setting.
> Both of these features/flags are disabled by default. You're welcome
> to handle the two patches separately.
More information about the hotspot-gc-dev