<div class="__aliyun_email_body_block"><div style="line-height:1.7;font-family:Tahoma,Arial,STHeiti,SimSun;font-size:14.0px;color:#000000;"><div style="clear:both;">Hi Andrew and Dean,</div><div style="clear:both;"><br ></div><div style="clear:both;">Thanks for reply. I checked the previous discussion and not clear about the root cause.</div><div style="clear:both;"><br ></div><div style="clear:both;">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.</div><div style="clear:both;"><br ></div><div style="clear:both;">I list some cases I'm thinking</div><div style="clear:both;">1) loaded value is used by final filed store, like</div><div style="clear:both;"> x.final_field=x.other +1;</div><div style="clear:both;"> it has data dependency, and can not be reordered by compiler</div><div style="clear:both;"><br ></div><div style="clear:both;">2) load from final field after final store</div><div style="clear:both;"> x.final_field = xxx; t=x.final_field;</div><div style="clear:both;"> The loaded value is always the final value. It's safe to elide below the barrier.</div><div style="clear:both;"><br ></div><div style="clear:both;">3) load from final field before final store</div><div style="clear:both;"> t=x.final_field; x.final_field = xxx;</div><div style="clear:both;"> The load could be elided with a non-final value, but it looks an expected behavior.</div><div style="clear:both;"><br ></div><div style="clear:both;">Thanks,</div><div style="clear:both;">Kuai Wei</div><div style="clear:both;"><br ></div><div style="clear:both;"><br ></div><div style="margin:.0px .0px .0px 30.0px;font-family:Tahoma,Arial,STHeiti,SimSun;font-size:14.0px;color:#000000;"><div style="clear:both;">From: <strong class="gmail_sendername">Andrew Haley</strong> <<a href="mailto:aph-open@littlepinkcloud.com" target="_blank">aph-open@littlepinkcloud.com</a>><br ></div><div ><div class="gmail_quote"><div class="gmail_attr">Date: Wed, Jan 10, 2024 at 5:54 PM<br >Subject: Re: discuss about release barrier for final fields initialization<br >To: <<a href="mailto:hotspot-compiler-dev@openjdk.org" target="_blank">hotspot-compiler-dev@openjdk.org</a>><br ></div><br ><br >On 1/9/24 06:23, Kuai Wei wrote:<br >
> I found only C2 will insert release membar and C1 just insert storestore for both final and normal allocation. In Doug Lea's cookbook <a href="https://gee.cs.oswego.edu/dl/jmm/cookbook.html" target="_blank">https://gee.cs.oswego.edu/dl/jmm/cookbook.html</a> <<a href="https://gee.cs.oswego.edu/dl/jmm/cookbook.html" target="_blank">https://gee.cs.oswego.edu/dl/jmm/cookbook.html</a>><br >
> Only storesotre is required. Alex has a great post on this topic <a href="https://shipilev.net/blog/2014/all-fields-are-final/" target="_blank">https://shipilev.net/blog/2014/all-fields-are-final/</a> <<a href="https://shipilev.net/blog/2014/all-fields-are-final/" target="_blank">https://shipilev.net/blog/2014/all-fields-are-final/</a>> . It referred a case why loadstore is needed. <a href="https://www.hboehm.info/c++mm/no_write_fences.html" target="_blank">https://www.hboehm.info/c++mm/no_write_fences.html</a> <<a href="https://www.hboehm.info/c++mm/no_write_fences.html" target="_blank">https://www.hboehm.info/c++mm/no_write_fences.html</a>><br ><br >
> 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<br >
> break on modern architecture. Is there other case I missed?<br ><br >
I think it requires a very careful analysis of the compiler to be sure.<br >
The problem occurs if an optimizer knows what a store is going to do. If<br >
it does, then there's nothing to prevent a load from being elided, and your<br >
load dependency has gone. This isn't a problem with C1, because C1 doesn't<br >
do that kind of optimization. I don't know that C2 does either, or even<br >
whether it is allowed to do so.<br ><br >
From what I remember of the conversation, we left the release barrier in<br >
because of an abundance of caution rather than any proof that a storestore<br >
was inadequate.<br ><br >
-- <br >
Andrew Haley (he/him)<br >
Java Platform Lead Engineer<br >
Red Hat UK Ltd. <<a href="https://www.redhat.com" target="_blank">https://www.redhat.com</a>><br ><a href="https://keybase.io/andrewhaley" target="_blank">https://keybase.io/andrewhaley</a><br >
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671<br ><br ></div></div></div><div style="line-height:20.0px;clear:both;"><br ></div></div></div>