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

[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

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671