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

[Roland Westrelin]

Hi Andrew,

> Ok, so that means you can have two successive stores to the same field
> and if we get here we know the second one has associated memory
> barriers. What guarantees that the first one will also have memory
> barriers? Obviously, the field may itself be declared as volatile and
> this code may arise from a standard putfield. However, what about the
> case where the field might be written firstly using Unsafe.putXXX and
> then using Unsafe.putXXXVolatile? Is that not possible?

I'm confused: what is the concern here?

Do we agree that dropping barriers on non escaping objects is ok?

Is the concern that we would optimize a store out that shouldn't be
optimized out? Or that membars would be removed where they are still
needed?

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?

Roland.