(original) (raw)

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@oracle.com> wrote:

On Jun 17, 2015, at 12:03 PM, Vladimir Kozlov <vladimir.kozlov@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