RFR: ShConcurrentThread races with set_gc_state_bit

[Zhengyu Gu]

661 void ShenandoahHeap::set_gc_state_bit_concurrently(uint bit, bool 
value) {
1662   _gc_state.set_cond(bit, value);
1663   MutexLocker mu(Threads_lock);
1664   JavaThread::set_gc_state_all_threads(_gc_state.raw_value());


I wonder if you want to move _gc_state.set_cond(bit, value) into locked 
section? In case that global state is set, then we hit a safepoint ... 
not sure if it is matter.

Otherwise, it looks good.

Thanks,

-Zhengyu

On 01/16/2018 02:24 PM, Aleksey Shipilev wrote:
> http://cr.openjdk.java.net/~shade/shenandoah/single-flag-races/webrev.01/
> 
> Zhengyu found this peculiar race:
> 
> When ShConcurrentThread sets {evac,update_refs}_in_progress, the set_gc_state_bit checks for the
> safepoint. It turns out, after we checked for the safepoint and entered the Thread_lock-free branch,
> the safepoint may be over. The way out is to restore the *_concurrent family of methods, and acquire
> Thread_lock there unconditionally.
> 
> Testing: hotspot_gc_shenandoah
> 
> Thanks,
> -Aleksey
>