RFR(M): 8209420: Track membars for volatile accesses so they can be properly optimized

[Roland Westrelin]

Hi Andrew,

Thanks for looking at this.

> The trailing and leading membars are removed along with their associated
> store when:
>
> 1) the store saves a value that was just loaded from the same address
> 2) the store repeats a directly preceding store to the same address
> 3) the store writes zero to a newly allocated (hence zero) object
>      (and ReduceFieldZeroing is set)
> 4) the store rewrites zero write to the same address as a still visible
> prior store
>       (and ReduceFieldZeroing is set)
>
> This looks fine when dealing with stores to non-volatile fields but I
> don't follow how it works when writing to volatile fields.

1) to 4) above only apply to non volatile fields unless the field's
object is non escaping, in which case they also apply to volatile
fields. For a volatile store, the store's memory input is a projection
of a membar. All transformations expect a particular memory input that
can't be a membar. So they are not applied to volatile fields. If an
object is non escaping, the memory graph is rewired (the volatile field
gets its own slice). The memory input of a volatile store to a non
escaping object is then no longer the membar. 1) to 4) may apply.

I could add an assert to check that we're dropping membars only for non
escaping objects.

Roland.