Integration of ParralellGC and CMS

[Tony Printezis]

Clemens,

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,

Tony

>>  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
>