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

[John Rose]

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/4d42da35/attachment.html>