Simplifying the BarrierSet hierarchy

[Mikael Gerdin]

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.

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

/Mikael

>
> Any opinions?
>
> Cheers,
> Roman
>