discuss about release barrier for final fields initialization

[Andrew Haley]

On 1/9/24 06:23, Kuai Wei wrote:
>    I found only C2 will insert release membar and C1 just insert storestore for both final and normal allocation. In Doug Lea's cookbook https://gee.cs.oswego.edu/dl/jmm/cookbook.html <https://gee.cs.oswego.edu/dl/jmm/cookbook.html>
> Only storesotre is required. Alex has a great post on this topic https://shipilev.net/blog/2014/all-fields-are-final/ <https://shipilev.net/blog/2014/all-fields-are-final/> . It referred a case why loadstore is needed. https://www.hboehm.info/c++mm/no_write_fences.html <https://www.hboehm.info/c++mm/no_write_fences.html>

> I checked this case and IMO it looks some legacy architecture may break data dependency and cause problem. As I know, alpha architecture is an example. I think it doesn't
> break on modern architecture. Is there other case I missed?

I think it requires a very careful analysis of the compiler to be sure.
The problem occurs if an optimizer knows what a store is going to do. If
it does, then there's nothing to prevent a load from being elided, and your
load dependency has gone. This isn't a problem with C1, because C1 doesn't
do that kind of optimization. I don't know that C2 does either, or even
whether it is allowed to do so.

 From what I remember of the conversation, we left the release barrier in
because of an abundance of caution rather than any proof that a storestore
was inadequate.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671