Re: discuss about release barrier for final fields initialization

[Kuai Wei]

Hi Andrew and Dean,
Thanks for reply. I checked the previous discussion and not clear about the root cause.
If you can provide more detail about the optimize, like what load or load dependency will be elided, so we may check chance to detect or prevent.
I list some cases I'm thinking
1) loaded value is used by final filed store, like
 x.final_field=x.other +1;
 it has data dependency, and can not be reordered by compiler
2) load from final field after final store
 x.final_field = xxx; t=x.final_field;
 The loaded value is always the final value. It's safe to elide below the barrier.
3) load from final field before final store
 t=x.final_field; x.final_field = xxx;
 The load could be elided with a non-final value, but it looks an expected behavior.
Thanks,
Kuai Wei
From: Andrew Haley <aph-open at littlepinkcloud.com <mailto:aph-open at littlepinkcloud.com >>
Date: Wed, Jan 10, 2024 at 5:54 PM
Subject: Re: discuss about release barrier for final fields initialization
To: <hotspot-compiler-dev at openjdk.org <mailto:hotspot-compiler-dev at openjdk.org >>
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 > <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/ > <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 > <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://www.redhat.com >>
https://keybase.io/andrewhaley <https://keybase.io/andrewhaley >
 EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-compiler-dev/attachments/20240111/8dfdcc56/attachment.htm>