[External] : Re: Why is mark read as MO_RELAXED in read_stable_mark()?

[patricio.chilano.mateo at oracle.com]

On 7/18/21 9:35 PM, David Holmes wrote:
> Hi Roman,
>
> Sorry for the delay in getting to this ...
>
> On 13/07/2021 7:18 am, patricio.chilano.mateo at oracle.com wrote:
>>
>> On 7/12/21 4:26 PM, Roman Kennke wrote:
>>>>> Hi Hotspot runtime devs,
>>>>>
>>>>> I am messing a little bit with read_stable_mark() in 
>>>>> synchronizer.cpp in Lilliput project (because I want to load the 
>>>>> Klass* from the header).
>>>>>
>>>>> I notice that, in read_stable_mark(), we are loading the header 
>>>>> with MO_RELAXED memory ordering, even though the INFLATING header 
>>>>> is stored either via CAS or (re-)stored with MO_RELEASE. Wouldn't 
>>>>> it be more consequential to load the header with MO_ACQUIRE instead?
>>>> For the monitor case I think we already have an address dependency 
>>>> in the reader so there is no need for the acquire. So we first read 
>>>> the monitor address and then use that address to access the _header 
>>>> field(FastHashCode() case) or _owner 
>>>> field(current_thread_holds_lock() and get_lock_owner() cases). The 
>>>> writer in turn orders the stores to _owner/_header and the 
>>>> publishing of the monitor address by using a release store in 
>>>> inflate() (I think this is the one you are referring to).
> I'm not convinced we can rely on any address dependency for semantics 
> in shared code - and it seems too subtle a point even if we can.
I did some investigation to try to answer that and see how reliable the 
current code is. It is indeed possible for the stores to _header and 
_owner in inflate() to still not be visible to the reader after it reads 
the new monitor address, although in practice that could only happen on 
DEC Alpha which doesn't preserve data dependency ordering ([1], [2]), or 
when compiler optimizations such as value speculation break the 
dependency chain [3] (although I don't think there is much room for that 
in these cases). C++ consume semantics(temporarily deprecated in C++17) 
appears to have been introduced to guarantee memory ordering in these 
cases where dependencies can be used to avoid the more expensive acquire 
semantics.

Patricio

[1] 
https://preshing.com/20140709/the-purpose-of-memory_order_consume-in-cpp11/#data-dependency-ordering
[2] http://www.cs.umd.edu/~pugh/java/memoryModel/AlphaReordering.html
[3] https://lwn.net/Articles/588300/
> Cheers,
> David
>
>> Thanks,
>> Patricio