Is the JMM spec progressing?

[Hans Boehm]

I think it's safe to say that it has been slow going, not just for Java,
but for other languages as well.

In my view, the core problem, shared by pretty much all of them, is that we
don't have an established way to give well-defined semantics to potentially
racing unordered accesses, like ordinary variable accesses in Java, or
memory_order_relaxed accesses in C and C++. That's particularly essential
with the traditional Java language-based-security model, since we can't
just give up on racing accesses to ordinary variables.

I'm aware of a number of proposed solutions. But I don't think we currently
have enough confidence that they

a) Are correct, and don't have issues similar to the older models,
a) Don't have unintended consequences, particularly for compilation, and
b) Are sufficiently comprehensible by programmers to actually be useful.

(a) is hard because the models have gotten complex enough that reviewers
are scarce. (A problem that I gather you're familiar with.) The authors are
commonly experts at formally analyzing the models, but it's hard to analyze
whether the model conflicts with some well-known, but perhaps not
well-written-down compilation technique.

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

It might be possible to do what we've involuntarily done for C++: Punt the
hard cases for now, and define what the model is for programs without
racing ordinary accesses.


On Fri, Aug 6, 2021 at 6:57 AM Raffaello Giulietti <
raffaello.giulietti at gmail.com> wrote:

> Hello,
>
> "JEP 188: Java Memory Model Update" [1], the JMM wiki [2] and the
> jmm-dev mailing list [3] seem quite inactive. (The latter point explains
> why I'm posting to this list instead.)
>
> The introduction of j.l.i.VarHandle [4] brought more access modes to
> Java, but in a narrative and informal way. A paper by Bender & Palsberg
> [5], addressing the formalization of the concurrent access modes, has
> been published in 2019 but I'm not sure if it caught the attention of
> the OpenJDK community.
>
> So what is the current thinking for progressing the JMM spec?
>
>
> Greetings
> Raffaello
>
> ----
>
> [1] https://openjdk.java.net/jeps/188
> [2] https://wiki.openjdk.java.net/display/jmm/Main
> [3] https://mail.openjdk.java.net/pipermail/jmm-dev/
> [4]
>
> https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/lang/invoke/VarHandle.html
> [5] https://dl.acm.org/doi/10.1145/3360568
>