RFR: Better handling of cancelled_gc

[Roman Kennke]

Am Mittwoch, den 09.11.2016, 09:54 -0500 schrieb Zhengyu Gu:
> I am not sure I agree with OrderAccess change. I don't think
> release_store/load_acquire semantic
> applies here...

You are right. the flag is the shared data, therefore I think correct
would be: acquire() loadflag() on the checking side, and storeflag()
release() on the setting side.

> Besides, if cancel_congc happens rarely, a full fence is not that
> bad. A barrier in checking code,
> which executes at much higher rate, may not yield any benefit.

Acquire should only be compiler barrier on x86. The benefit is that we
don't end up with threads not observing the changed value (also done by
volatile, at least on x86).

I believe it's correct like this:

http://cr.openjdk.java.net/~rkennke/cancelgc/webrev.03/

Ok to push now?

Roman

> 
> Thanks,
> 
> -Zhengyu
> 
> 
> 
> 
> 
> On 11/09/2016 09:20 AM, Roman Kennke wrote:
> > 
> > This patch:
> > - Makes _cancelled_gc volatile and accessed by load_acquire and
> > release_store so that observing threads are seeing changes quickly
> > instead of checking cached values
> > - Improve the concurrent mark loop so that it doesn't check that
> > flag
> > on every iteration, but only every 1000th iteration, which should
> > be
> > plenty fast enough
> > 
> > http://cr.openjdk.java.net/~rkennke/cancelgc/webrev.01/
> > 
> > OK?
> > 
> > Roman
> > 
>