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

[Andrew Haley]

On 08/14/2018 10:50 AM, Andrew Dinn wrote:
> On 14/08/18 09:55, Roland Westrelin wrote:
>> I'm confused: what is the concern here?
>>
>> Do we agree that dropping barriers on non escaping objects is ok?
> 
> That is what I am worrying about.

It is OK because there is nothing for the stores to synchronize with.

> 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.

Think about this in terms of happens before.  A store to a volatile
happens before a read of the same volatile.  All plain stores in
program order beforehand happen before the volatile store.  So, the
plain stores are visible to another thread after it reads the value
from the volatile store.

However, if the value in the volatile store is never read, there is no
ordering requirement and no need to make prior plain stores visible to
another thread.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671