RFR: 8310939: [c1] The visibility of write-volatile requires membar_volatile instead of membar

[Andrew Haley]

On Tue, 27 Jun 2023 12:46:14 GMT, SUN Guoyun <duke at openjdk.org> wrote:

> For c1 now, a volatile write case:
> 
> membar_release // LoadStore | StoreStore
> write volatile
> membar
> 
> Just like c2, here `membar` should be defined `membar_volatile` clearly, then for risc-v, ppc and loongarch can use StoreLoad for `membar_volatile` for better performance.
> 
> Testing:
> GHA testing
> jtreg tier1-3 for loongarch64

> _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on [hotspot-dev](mailto:hotspot-dev at mail.openjdk.org):_
> > 
> > I know that this patch is now withdrawn, but I'd like to make a point.
> > Please don't use terms like volatile_write_post_barrier for StoreLoad
> > if you can possibly avoid it, because that's only one way to implement Java's volatile.
> > The assumption that volatile write is implemented by release; write; StoreLoad
> > or similar permeates HotSpot, and is a pain for architectures like AArch64
> > which that don't do volatile that way.
> 
> My long term understanding of the issue is that the requirements for volatile accesses is determined by the nature of the surrounding accesses - as per Doug Lea's JMM Cookbook [1].

That is to say, if you have to implement volatile using plain memory accesses and fences, then you are going to need a StoreLoad between a plain store and a plain load in the same thread. But the JMM Cookbook is of historical interest only, because there are now alternative ways to do it. 

> But neither the interpreter nor C1 consider this and only apply barriers to the actual volatile read/write in isolation - hence they (have to) assume the worst-case and use the strongest pre/post barriers that may be needed. And of course the kinds of barriers available depend on architecture.

They don't have to do that: they could simply have punted volatile-store/volatile-load to the back end.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14677#issuecomment-1647642736