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

[Roland Westrelin]

>> A store has 2 membars one before, one after (unless
>> support_IRIW_for_not_multiple_copy_atomic_cpu is true). So if one access
>> is a volatile access and the other one is not, a barrier should be
>> between the 2 stores anyway and it would prevent optimizations?
>
> Ok, so I am still confused by how this relates to what you said earlier:

Ignore that one. It was a comment under the assumption that you were
not concerned by non escaping objects.

> So, let's assume we are looking at the case where we have a non-escaping
> object and have two successive stores, the first an unsafe putXXX and
> the second a putXXXVolatile. In that case what does the graph look like?
>
> Will memory barriers be present?

Before optimizations, yes.

> Will they be attached to the 2nd store as leading and trailing barriers?

Yes.

> Will the optimization be applicable to this case or does it only apply
> when the first store also has associated barriers?

I think it would be applicable.

> If the optimization does apply to this case then can we arrive at the
> situation where removal of the second store and its associated barriers
> leaves a single non-volatile store without any barriers?
>
> If we get to that last case then the resulting graph would generate code
> that would fail to guarantee visibility of writes prior to the first store.

If the object is non escaping, then there's a good chance the object
won't exist in the final graph and none of the stores will be there
either because they don't have anything to store to.

Also, given the object is non escaping, noone can observe the stores. So
why does it matter?

Roland.