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

[David Holmes]

On 20/07/2023 10:43 pm, Andrew Haley wrote:
> On 7/19/23 21:39, Dean Long wrote:
>> It's confusing to me to rename the post-barrier but not the 
>> pre-barrier.  Instead of changing membar_release + membar to
>> membar_release + membar_volatile, something like 
>> volatile_write_pre_barrier + volatile_write_post_barrier in the shared 
>> code makes more sense to me.
> 
> 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]. 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.

David
-----

[1] https://gee.cs.oswego.edu/dl/jmm/cookbook.html

> [ Comment for people reading this who don't know how AArch64 does work.
> 
> AArch64 uses an instruction that acts something like
> 
>    release; store   (called LDAR)
> 
> for a volatile write, and
> 
>    <StoreLoad if needed> ; load ; acquire   (called STLR)
> 
> for a volatile read.
> 
> Note: this isn't the full story, and you have to look at the definition
> of things like barrier-ordered-before to know all the details. ]
>