[concurrency-interest] Programming language-independent memory models

Andrew Haley aph at redhat.com
Mon Aug 7 04:46:31 EDT 2017

On 05/08/17 06:04, Hans Boehm wrote:
> The problem is that there are actually semi-rational reasons for the
> differences between the C++ and Java memory models. And we tried to make
> the two as similar as possible were such reasons didn't exist.
> Java wanted to avoid undefined behavior (for the core language) at
> pretty much all costs. The costs unfortunately include:
> - Fences in object constructors
> - New (for C++) optimization constraints, e.g. the inability to
> rematerialize spilled registers from globals

Really?  I didn't realize that was a change, and I suspect that
compilers still do it.

> - Serious definitional problems with out-of-thin-air results for
> basically every program (as opposed to just memory_order_relaxed
> accesses in C++)
> These were probably reasonable tradeoffs for Java, especially at the time.
> But I don't think they would fly for C or C++.

OK, thanks for that explanation.  But there are many languages around,
and many of them allow multiple threads, and many of those allow
concurrent access to shared state.  There is no way that language
designers are going to be able to put in the amount of work needed to
define a memory model for their language.  If they run on x86 they'll
usually be fine, of course!  Perhaps what they need is some kind of
boilerplate for a language memory model.

> I'm not sure that using memory_order_relaxed in a Java interpreter is that
> much of an issue, given that JIT-compiled code would still benefit from the
> weaker Java semantics. For the few cases for which this is seriously
> suboptimal, e.g. long accesses on mips32, you could resort to assembly code.

That makes sense.

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

More information about the Concurrency-interest mailing list