CMS parallel initial mark
Hiroshi Yamauchi
yamauchi at google.com
Fri Jun 7 18:46:58 UTC 2013
> >>> - in concurrentMarkSweepGeneration.cpp in
> > >>> CMSCollector::checkpointRootsInitialWork() the new code seems a
> little
> > >>> strange to me. I.e. roughly it does the following:
> > >>>
> > >>> [...]
> > >>> if (CMSParallelInitialMarkEnabled) {
> > >>> [ set up parallel stuff ]
> > >>> if (n_workers > 1) {
> > >>> // do parallel thread
> > >>> } else {
> > >>> // do serial work using the current thread
> > >>> }
> > >>> } else {
> > >>> // do serial work
> > >>> }
> > >>>
> > >>> it does not feel good to have two serial paths here; maybe use the
> > >>> serial/original code if n_workers == 1 and guarantee(n_workers > 1,
> ) in
> > >>> the first part of the if? Or look if the old serial path could be
> > >>> removed? (or the new one).
> > >> Is the inner serial path one thread executing a single chunk that
> > >> does all the work (i.e., executes the parallel code but by only
> > >> one thread)?
> > > Yes, that is in my opinion a little awkward. It would be nice if we had
> > > only one serial initial marking code path to simplify
> > > debugging/maintenance if there are issues. Removal of one or the other
> > > (if so) probably depends on how different the performance between the
> > > two paths is.
> >
> > I would prefer not to remove the path that executes the parallel code
> > with a single thread. It is a tool for looking for performance anomalies
> > in the parallel code. I've used code like it (i.e., executes parallel
> > code in
> > one thread in UseParallelGC and UseParNewGC) this week while looking
> > for a performance problem.
> >
> > The strictly serial path (which is the code we have today) would be nice
> > to have for a while as a workaround for any problems.
>
> Okay, fair enough.
>
>
I'll keep the code as is, keeping the two serial code paths. To add my 2
cents, I think a similar pattern existed in the CMS code
(eg. CMSCollector::do_remark_parallel()), and that's probably why I
followed the same pattern there.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20130607/90a6a52f/attachment.htm>
More information about the hotspot-gc-dev
mailing list