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

[Andrew Dinn]

On 14/08/18 11:01, Roland Westrelin wrote:
>> 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?
Aaargh, of course. Thank you for your patience in explaining this :-)

In that case I am happy with the current patch as a replacement for what
we currently have.

If Andrew Haley wants AArch64-specific fixes for other Unsafe operations
that currently rely on barriers I'd strongly recommend that as a
follow-up. This fix does not make anything worse and avoids the
possibility of further GC barrier changes causing AArch64 breakage.

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander