Simplifying the BarrierSet hierarchy

[Thomas Schatzl]

Hi,

On Tue, 2016-11-22 at 15:08 +0100, Mikael Gerdin wrote:
> Hi Roman,
> 
> On 2016-11-22 12:22, Roman Kennke wrote:
> > 
> > While working on the GC interface prototype, I made a sketch of the
> > current BarrierSet hierarchy:
> > 
> > x  BarrierSet
> > x   ModRefBarrierSet
> > x     CardTableModRefBS
> > x      G1SATBCardTableModRefBS
> > g       G1SATBCardTableLoggingModRefBS
> > p      CardTableExtension
> > c      CardTableModRefBSForCTRS
> > 
> > x - not used anywhere
> > g - used by G1
> > p - used by parallel
> > c - used by CMS
> > 
> > I've got a couple of questions:
> > 
> > - Is that correct and complete? Especially for CMS, is it only
> > using CardTableModRefBSForCTRS and is it the only user of that
> > class? I am asking, because I want to do the oop_store()
> > refactoring as outlined in the GC interface JEP, and if it's only
> > used for CMS, I can move the special oop_store() handling to there.
> CardTableModRefBSForCTRS is used by all the "framework" collectors,
> i.e. the ones using GenCollectedHeap.
> At this point we've reduced that to be just "UseSerialGC" and 
> "UseConcMarkSweepGC" but IIRC the flag "UseParNewGC" is still
> available for experimenting.
> 
> I suspect that CardTableModRefBSForCTRS contains a fair bit of code
> that is only used when ParNew is the young gc and not so much which
> is specific to CMS as the old gen collector but that is just my gut
> feeling about the code.

Also base classes like CardTableModRefBS contain quite a bit of code
that is only used by some collectors (generational framework collectors
and/or parallel gc, or only in parallel gc) but not in others.

The distinction what code belongs to what collector is not that easy at
the moment. It would be nice to improve this situation.

As you might have noticed while looking through the code, particularly
G1's card table memory management does not have a lot in common with
the others. G1SATBCardTableLoggingModRefBS only provides minimal
support code, overrides all absolutely necessary methods and gets away
with not calling any methods related to other collector's card table
memory management...

> > - Is there any reason against simplifying that hierarchy? In
> > particular, I would collapse unused classes like this:
> > 
> > x  BarrierSet
> > x   CardTableModRefBS
> > g    G1SATBCardTableLoggingModRefBS
> > p    CardTableExtension
> > c    CardTableModRefBSForCTRS
> > 
> > I.e. merge ModRef with CardTableModRef and G1SATBCardTable with
> > G1SATBCardTableLogging.
> In discussions and thoughts around the "Throughput barriers for G1" 
> concept we've thrown around the idea of utilizing the fact that G1
> has two separate BarrierSet subclasses already to implement the two 
> different variants of write barriers for G1 but that code can always
> be reintroduced when we get to that point. It's not certain that how
> it looks today is optimal for that case either.

I think this additional BarrierSet could be easily reintroduced later;
particularly the card table memory management that is part of the
BarrierSet will very likely stay the same as in current G1 anyway.

Thanks,
  Thomas