Integration of ParralellGC and CMS
tony.printezis at oracle.com
Thu Jan 27 08:55:26 PST 2011
Clemens Eisserer wrote:
> If the stw compaction phase would be executed after a "normal" CMS
> run, couldn't the marking results of the concurrent marking phase be
> used? All created objects since then could be simply treated as alive.
> Probably moving all objects (live or dead) would be an option too, but
> of course would mean more work and worse compaction.
(If I understand your intent correctly and to expand a bit on what Jon
said) Simply relying on the marking information to compact objects (i.e.
move the live ones) is not sufficient. Finding which objects to move is
one part of this. But the harder part is to make sure that you find all
the references to the objects that are being moved and update them. If
you want to move a subset of the marked objects, unless you somehow keep
track of where the references into that subset are, you'd have to scan
the entire heap to to the reference updating and this can take a very
long time. If instead you want to perform a full parallel compaction at
the end of the CMS marking cycle using the marking information that CMS
obtained, then this stop-the-world Full GC pause could be shorter than
what say ParallelOldGC does (given that it does need to do the marking
phase). But it would be at the same order of magnitude as a
ParallelOldGC Full GC, so not a huge improvement. Typically initial-mark
/ remark pauses in CMS are considerably shorter than Full GCs.
Anyway, hope this helps,
>> Look at the
>> serial old gen collector if you're interested in this. The ParallelOldGC
>> will be somewhat more complicated. We're not particularly
>> interested in it because that's what G1 does.
> Hmm, if it would work well and the code would be clean, small and
> maintainable - would there be a chance for integration?
> I asked here, because it would be great if the stuff i produce during
> working on a master thesis could be useful ;)
> Thanks, Clemens
More information about the hotspot-gc-dev