RFR: Better handling of cancelled_gc

[Roman Kennke]

Am Mittwoch, den 09.11.2016, 15:02 +0000 schrieb Andrew Haley:
> On 09/11/16 14:54, Zhengyu Gu wrote:
> > 
> > I am not sure I agree with OrderAccess change. I don't think
> > release_store/load_acquire semantic
> > applies here...
> 
> It doesn't, but it will work because cancelled_concgc() is polled in
> a loop.
> 
> +    OrderAccess::release_store(&_cancelled_concgc, true);
> 
> This should be release_store_fence()

Right!

So just for the record, the way to publish and access shared flags
is:

- make flag volatile
- Use OrderAccess::load_acquire() to access
- Use OrderAccess::release_store_fence() to publish

It's debatable whether or not the acquire and release parts are
strictly required. It sure is conservative and should help prevent
nasty surprises. And it's looking good because of symmetry :-) I think
unless any of this stuff happens in hot code paths, it should be fine.

I fixed some more issues. Some places accessed _cancelled_concgc
directly, they are now using the accessor too. Also,
clear_cancelled_concgc() was accessing the flag directly too. I made a
setter that does the correct thing and used that everywhere.

There was one cancelled_concgc() check in evacuate_object(), that would
shortcut evacuation if cancelled. I think this is outright wrong &
dangerous: if a Java thread gets there and finds that evacuation is
cancelled and returns the brooks ptr of the object, there is a chance
that another thread (Java or GC) is still evacuating the object, and
the first thread gets away with a from-space object. I removed this.
The correct thing to do is to let that thread fail allocation and run
into oom_during_evacuation() which will make it wait until evacuation
is settled and it can safely return the brooks ptr (evacuated or not).

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

Ok now?

Roman