RFR(M): 8080289: Intermediate writes in a loop not eliminated by optimizer

[Vitaly Davidovich]

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).

On Wed, Jun 17, 2015 at 3:31 PM, John Rose <john.r.rose at oracle.com> wrote:

> On Jun 17, 2015, at 12:03 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com>
> wrote:
>
>
> 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.
>
>
> Here's my a warning about this:  New optimizations sometimes uncover
> implicit dependencies
> by badly-written user code on memory effect ordering.  The user code is
> bad, but sometimes you
> need to be able to suppress the optimization anyway.  You might suppress
> only as long
> 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.
> (Think of it as an indefinitely delayed optimization of an indefinitely
> delayable store.)
>
> We have to be careful about fences, both emitting them into IR and
> respecting them once there.
> It is likely that we have enough fences to implement the JMM at current
> optimization levels,
> but perhaps we need a few more if we reorder stores more aggressively.
> The important thing to remember is that the JMM is not defined in terms of
> fences;
> the fences are a means to an end in enforcing happens-before relations.
>
> An *activated* safepoint might want fence-like behavior w.r.t. aggressive
> optimizations.
> For example, if we delay a store indefinitely because of a loop, and the
> loop hits
> an active safepoint, an early store might need to be flushed out.
>
> Even if a safepoint doesn't need such "flushing" behavior per the JMM, we
> might
> want that anyway to preserve some basic "liveliness" on the JVM's behavior.
> It feels possibly correct and definitely surprising to delay a store
> indefinitely.
>
> All that said, the JMM gives us permission to perform very aggressive
> optimizations.
> So let's do them.
>
> — John
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20150617/eb541fe5/attachment.html>