RFR: Refactor conc-mark-in-progress/satb-active flags to use gc-phase-in-progress

[Aleksey Shipilev]

On 09/29/2017 04:59 PM, Roman Kennke wrote:
> http://cr.openjdk.java.net/~rkennke/satb-concmark-flag/webrev.04/

 *) This still touches the G1 codepath in g1_pre_barrier_slow_id, please revert. Is this the
optimization you wanted to upstream? Upstream it then, and it will come back to us via the regular
channel;

 *) I don't understand the change of is_concurrent_mark_in_progress() to static function. This is
inconsistent with other flags in the heap. Is this for performance? Because in most uses I can see
ShenandoahHeap* is already available. ShenandoahBarrierSet::enqueue might just use
ShenandoahHeap::heap(), because it does not seem very heavy.

 *) I wonder if changing the poll from SATB_MQ_set().is_active() to is_conc_mark_in_progress() is
actually correct? Can we have the disparity between these two flags, causing us to lose values when
SATB is still supposed to be active? E.g. some weird weak references / keep-alive barrier interaction?

Thanks,
-Aleksey