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

[Roman Kennke]

Am 28.09.2017 um 12:07 schrieb Andrew Haley:
> On 28/09/17 10:38, Roman Kennke wrote:
>> Am 27.09.2017 um 16:43 schrieb Aleksey Shipilev:
>>> On 09/25/2017 06:59 PM, Roman Kennke wrote:
>>>> http://cr.openjdk.java.net/~rkennke/satb-concmark-flag/webrev.02/
>>> So I am not happy with refactoring G1 codepaths: this will pose problems with merging from upstream,
>>> problems with backports, problems with testing, etc. Copy-paste Shenandoah paths out (that would
>>> probably disentangle Shenandoah going via g1_* stubs too?), and then we wait for GC interface to
>>> arrive to remove that copy-paste.
>> Ok, I see your point. I changed the barrier code as you suggested and
>> leave G1 barriers alone.
>>
>> Tested again on x86 and aarch64: hotspot_gc_shenandoah
>>
>> http://cr.openjdk.java.net/~rkennke/satb-concmark-flag/webrev.03/
>> <http://cr.openjdk.java.net/%7Erkennke/satb-concmark-flag/webrev.03/>
>>
>> Ok now?
> Assert this:
>
> +  // (The index field is typed as size_t.)
>
> +  add(tmp, tmp, rscratch1);             // tmp := tmp + *buffer_adr
> +
> +  // Record the previous value
> +  str(pre_val, Address(tmp, 0));
>
> Should be
>
>     str(pre_val, Address(tmp, rscratch1);
>
> This comment is wrong:
>
> +  } else if (UseShenandoahGC && ShenandoahKeepAliveBarrier) {
> +    enter(); // g1_write may call runtime
>
Right, this looks better. This code is copy+pasted from upstream G1 
barrier code. Do you think it's worth opening a bug upstream?

http://cr.openjdk.java.net/~rkennke/satb-concmark-flag/webrev.04/ 
<http://cr.openjdk.java.net/%7Erkennke/satb-concmark-flag/webrev.04/>

Tested again on aarch64: hotspot_gc_shenandoah

Roman