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

[David Holmes]

On 19/07/2021 11:16 pm, Roman Kennke wrote:
>>>> Looking at the uses of read_stable_mark() I would say that 
>>>> FastHashCode and get_lock_owner() should have acquire semantics to 
>>>> match the implied release semantics used when there is inflation and 
>>>> those methods have to read fields of the monitor. 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.
>>>
>>> Ok, I agree.
>>>
>>>> The other uses don't need acquire semantics
>>>
>>> Why do you think so?
>>>
>>> I see a use in current_thread_holds_lock(), and how is that different 
>>> from get_lock_owner() ? It also reads a field of the monitor after 
>>> loading the header word.
>>
>> Because that thread is only interested in correctly seeing values 
>> written by itself. It can't get any kind of false positive. If it is 
>> the owner it must see its own writes; if it is not the owner it can't 
>> see itself incorrectly listed as the owner.
> 
> Right. Is it reasonable to make the distinction for that single case, 
> though? Adding acquire semantics should not make much of a difference 
> (if at all) to performance, in light of the other things that the method 
> does?

No I don't think it needs to make the distinction here. There are only 
three callers of this method anyway:
- Thread.holdsLock
- an obscure part of classloading (double-lock-wait)
- an assert

Thanks,
David

> Roman
>