CMS parallel initial mark

Jon Masamitsu jon.masamitsu at
Thu Jun 6 00:12:59 UTC 2013


I've looked at the parallel initial mark changeset so far.  Looks good.
Would you says that the FlexibleWorkerGang

// Parallel initial mark task
class CMSParInitialMarkTask: public CMSParMarkTask {
   FlexibleWorkGang* _workers;

is unused above just as it is unnecessary in the constructor for

I'll look at the second changeset in a bit.


On 5/30/2013 10:56 AM, Hiroshi Yamauchi wrote:
> Thanks, Jon. Please let me know when you know more.
> On Wed, May 29, 2013 at 6:37 PM, Jon Masamitsu <jon.masamitsu at> wrote:
>> Hiroshi,
>> I'm still reviewing the changes but so far this looks
>> very promising.  I've patched you changes into a repository
>> and started running a few tests.  I've turned on
>> -XX:+CMSParallelInitialMarkEnabled -XX:+CMSEdenChunksRecordAlways
>> Thanks.
>> Jon
>> On 5/28/2013 5:24 PM, Hiroshi Yamauchi wrote:
>>> Hi,
>>> 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.
>>> Thanks,
>>> Hiroshi

More information about the hotspot-gc-dev mailing list