<p dir="ltr">So I'm not sure how many cases will arise where scheduling stores is beneficial (on modern cpus) apart from removing redundant ones.  The compiler would need some seriously detailed machine model, I think, to reason about this intelligently.  Removing redundant ones (or moving loop invariant ones out of loops, like Roland is trying here) seems more tractable and beneficial? Are there cases beyond this where it would be profitable? Perhaps scheduling writes to addresses likely to be on same cacheline maybe ...</p>
<p dir="ltr">As for removing StoreStore barriers, it seems like that's practically feasible with java's semantics only when EA kicks in; I'm having a hard time imagining how the JIT can trace unsafe/racy publication reliably and with minimal overhead.  Perhaps I'm not thinking hard enough though ...</p>
<p dir="ltr">It's almost unfortunate that final fields were granted this right to be published unsafely :) - would've been perhaps better if explicit fencing was required for such specialized case.</p>
<p dir="ltr">sent from my phone</p>
<div class="gmail_quote">On Jun 17, 2015 5:27 PM, "John Rose" <<a href="mailto:john.r.rose@oracle.com">john.r.rose@oracle.com</a>> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><blockquote type="cite"><div class="quoted-text"><div>On Jun 17, 2015, at 1:23 PM, Vitaly Davidovich <<a href="mailto:vitalyd@gmail.com" target="_blank">vitalyd@gmail.com</a>> wrote:</div><br></div><div><div dir="ltr"><div class="quoted-text"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:12.8000001907349px">Nope, that's an oversimplified understanding.  One place where the JMM will bite you is with publication of object state via final fields. Normal stores used to initialize a structure which is published via final-field semantics must be ordered to take place before the object is published.  We don't (and perhaps can't) track object publication events, nor their relation to stores into newly-reachable subgraphs.  Instead, we have fences that gently but firmly ensure that data (from normal stores, even to non-final fields and array elements!) is posted to memory before any store which could be a publishing store for that data.</span></blockquote><div><span style="font-size:12.8000001907349px"><br></span></div></div><div><span style="font-size:12.8000001907349px">Not sure what's oversimplified —</span></div></div></div></blockquote><div><br></div><div>I probably misread you, then.</div><div class="quoted-text"><br><blockquote type="cite"><div><div dir="ltr"><div><span style="font-size:12.8000001907349px">you're describing a JMM semantic for final fields, which I'd expect to be modeled as barriers in the IR, just like volatile writes would be modeled as barriers, preventing removal or reordering of them.  I appreciate that it can be troublesome to track this information, but that only means compiler will have to play more conservative and there may be some optimization opportunities lost.  I'd think the pattern would look like:</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">obj = allocZerodMemory(); // obj has final fields</span></div><div><span style="font-size:12.8000001907349px">obj.ctor(); // arbitrarily long/complex CFG</span></div><div><span style="font-size:12.8000001907349px">StoreStore</span></div><div><span style="font-size:12.8000001907349px">_someRef = obj;</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">I'd expect redundant stores to be removed as part of ctor() CFG without violating the storestore barrier.  But, I do understand the complexity/trickiness of getting this right.</span></div></div></div></blockquote><div><br></div></div><div>You are correct.  The StoreStore approximates the point at which the object is first published to other threads.  All normal stores above the StoreStore can be issued in any order (as far as this fence is concerned) but must settle before the object is published.  Presumably it is published shortly after the StoreStore, and the StoreStore could be sunk until that point, if we wanted to do this, or even eliminated if the object never gets published.  Also, stores provably unrelated to (unreachable from) the published object could drop below the StoreStore.  We don't attempt to make this distinction.  None of these train of thought affects the basic assertion that (if fences are absent) normal stores can be reordered.</div><div><br></div><div>If we wish to remove that StoreStore (for some reason) we would either need a more precise set of fences (or HB edges), or else we would have to hold back on aggressive store reordering.  This is what makes me think we may discover a missing fence, once we start letting those little stores swarm around each other.</div><div><br></div><div>What makes me more nervous about this is the clear fact that non-TSO platforms (TSO, Itanium) have to tweak their fences in various ad hoc ways to avoid breaking user code.  See, for example, Parse::do_exits.  If we make our thread-local orderings more non-TSO-ish, we might run into the same subtle issues that the PPC port wrestles with.  By "subtle" I partly mean "relating to unstated user expectations even if not supported by the JMM", and I also mean "hard to detect, characterize, and fix".</div><font color="#888888"><div><br></div><div>— John</div></font></div></div></blockquote></div>