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

[Aleksey Shipilev]

On 10/02/2017 10:49 AM, Roman Kennke wrote:
> The original intention of the exercise was, when partial GC arrives, we need SATB buffers active
> both during conc-mark and conc-partial. Likewise, we need write-barriers active both during evac and
> conc-partial. My idea was that instead of checking both flags (and loading both flags) in hot paths
> (i.e. if (conc_partial_active || satb_active) ) we could load it once and do a masking test  ( i.e.
> if (gc_phase_active & (CONC_MARK | CONC_PARTIAL) != 0) and similar for evac). Another intended
> side-effect of this is when we get to the GC interface, and the GC barrier gets to handle to
> complete store, for oop stores we'd end up with: 1 write barrier and 1 satb-barrier during
> concmark/evac or even 2 write-barrier and maybe satb-kindof-like barriers during conc-partial. In
> this big block, we'd then only need to load the flag once, and check it a bunch of times in a row,
> for different bits.

...

> Opinions? Do you see other ways out? What should I do?

This _looks_ like premature optimization (coalescing phase bits) for the experimental code
(concurrent partial), that significantly increases our upstream exposure. Can we table it then, and
do explicit flags as upstream does now? Then, when concurrent partial graduates from experimental,
improve the shared code paths?

I'd probably be happy with experimental code if it did not touch the shared paths. But it does,
alas. So the experimental code should pay the maintenance and performance price (i.e. checking flags
several times), not the shared code.

Thanks,
-Aleksey