Integration of ParralellGC and CMS

[Jon Masamitsu]

On 1/27/2011 5:39 AM, Clemens Eisserer wrote:
> ...
>> A complete
>> marking of the live data would be needed for the increment of the
>> compaction.  But you'd only need to do the actual compaction (moving
>> data and adjusting pointers) on part of the old gen.
> 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.
>

I would not want to depend on the marking from a CMS concurrent 
collection.  I think
the first place I would use an incremental compaction is when a 
concurrent mode
failure had occurred and try an incremental compaction instead of a full 
compaction.
Eventually doing an incremental compaction in anticipation of a 
concurrent mode
failure would be desirable but I'm not sure we have the metrics to 
figure that out
reliably.  Even an incremental compaction is going to hurt so start by 
doing it only
when you have to.

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

I don't know the answer to that question.  It would seem silly for us 
not to accept but this
is a zero sum game.  The effort to productize such a project would have 
to take effort away
from something and I think that something else would be G1.

Jon