RFR: 8189871: Refactor GC barriers to use declarative semantics

[Aleksey Shipilev]

On 11/10/2017 05:29 PM, Erik Österlund wrote:
> 1) The barrier resolver loads the current barrier set, and checks the "name" of it (the enum value).
> 2) Each "name" for concrete barriers that you listed in barrierSetConfig.hpp is asked for...
> 3) ...the BarrierSet::GetType of that enum "name", and...
> 4) The AccessBarrier of that resulting BarrierSet (your ShenandoahBarrierSet) will be called.

So, I tried a simpler exercise with Epsilon, and it seems to work:
 http://cr.openjdk.java.net/~shade/epsilon/gc-barriers-declarative.patch

A few comments from that exercise:

 *) After the recent BS cleanup, the EpsilonBarrierSet has only a few leftovers [1]. With current
patch, write_ref_field_work seems to be gone. But write_ref_array_work and write_region_work are
still used. This removal is deliberately not handled in current patch, right?

 *) What is the meaning of AccesssBarrier::Raw like these?
  typedef BarrierSet::AccessBarrier<decorators, BarrierSetT> Raw;

  I am asking because it is not unclear if BS should typedef this. Epsilon seems to work fine
without the declaration. G1SATBCardTableLoggingModRefBS::AccessBarrier has it, but
CardTableModRefBS::AccessBarrier has not.

Thanks,
-Aleksey

[1]
http://hg.openjdk.java.net/jdk/sandbox/file/b2b4df384c83/src/hotspot/share/gc/epsilon/epsilonBarrierSet.hpp