Is the JMM spec progressing?

[Andrew Haley]

On 8/6/21 11:32 PM, Hans Boehm wrote:

> Probably even more controversially, I think we've realized that
> existing compiler technology can compile such racing code in ways
> that some of us are not 100% sure should really be allowed.

This implies, does it not, that the problem is not formalization as
such, but that we don't really understand what the language is
supposed to mean? That's always been my problem with OOTA: I'm unsure
whether the problem is due to the inadequacy of formal models, in
which case the formalists can fix their own problem, or something we
all have to pay attention to.

> Demonstrably unexecuted code can affect the semantics in ways that
> strike me as scary. (See wg21.link/p1217 for a down-to-assembly C++
> version; IIUC, Lochbihler and others earlier came up with some
> closely related observations for Java.)

Looking again at p1217, it seems to me that enforcing load-store
ordering would have severe effects on compilers, at least without new
optimization techniques. We hoist loads before loops and sink stores
after them. When it all works out, there are no memory accesses in the
loop. A load-store barrier in a loop would have the effect of forcing
succeeding stores out to memory, and forcing preceding loads to reload
from memory. It's not hard to imagine that this would cause an
order-of-margnitude performance reduction in common cases.

I suppose one could argue that such optimizations would continue to be
valid, so only those stores which would have been emitted anyway would
be affected. But that's not how compilers work, as far as I know. In
our IR for C2, memory accesses are not pinned in any way, so the only
way to make unrelated accesses execute in any particular order is to
add a dependency between all loads and stores.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671