<div dir="ltr">But happens-before is meaningful only for inter-thread communication.  If we're talking about plain stores with no fences (or let's say, JMM happens-before inducing points in between them), then as long as intra-thread semantics aren't violated, I'd say anything's on the table :).  Will this risk uncovering broken user code? Yes, but that code is a ticking time bomb anyway (and subject to CPU reordering as well).</div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 17, 2015 at 3:31 PM, John Rose <span dir="ltr"><<a href="mailto:john.r.rose@oracle.com" target="_blank">john.r.rose@oracle.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><span class="">On Jun 17, 2015, at 12:03 PM, Vladimir Kozlov <<a href="mailto:vladimir.kozlov@oracle.com" target="_blank">vladimir.kozlov@oracle.com</a>> wrote:<br><div><blockquote type="cite"><br><div><span style="font-family:Helvetica;font-size:16px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">If we can guarantee that all passed stores are normal (I assume we will have barriers otherwise in between) then I agree. I am not sure why we didn't do it before, there could be a counterargument for that which I don't remember. To make sure, ask John.</span></div></blockquote><br></div></span><div>Here's my a warning about this:  New optimizations sometimes uncover implicit dependencies</div><div>by badly-written user code on memory effect ordering.  The user code is bad, but sometimes you</div><div>need to be able to suppress the optimization anyway.  You might suppress only as long</div><div>as it takes to diagnose the bad code, but it might be a long time if the user can't or won't fix it.</div><div>(Think of it as an indefinitely delayed optimization of an indefinitely delayable store.)</div><div><br></div><div>We have to be careful about fences, both emitting them into IR and respecting them once there.</div><div>It is likely that we have enough fences to implement the JMM at current optimization levels,</div><div>but perhaps we need a few more if we reorder stores more aggressively.</div><div>The important thing to remember is that the JMM is not defined in terms of fences;</div><div>the fences are a means to an end in enforcing happens-before relations.</div><div><br></div><div>An *activated* safepoint might want fence-like behavior w.r.t. aggressive optimizations.</div><div>For example, if we delay a store indefinitely because of a loop, and the loop hits</div><div>an active safepoint, an early store might need to be flushed out.</div><div><br></div><div>Even if a safepoint doesn't need such "flushing" behavior per the JMM, we might</div><div>want that anyway to preserve some basic "liveliness" on the JVM's behavior.</div><div>It feels possibly correct and definitely surprising to delay a store indefinitely.</div><div><br></div><div>All that said, the JMM gives us permission to perform very aggressive optimizations.</div><div>So let's do them.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>— John</div></font></span></div></blockquote></div><br></div>