[concurrency-interest] Programming language-independent memory models

Hans Boehm boehm at acm.org
Tue Aug 8 15:10:11 EDT 2017


On Mon, Aug 7, 2017 at 1:46 AM, Andrew Haley <aph at redhat.com> wrote:
>
> 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.
Just to be clear: Java does not allow rematerializing spilled registers from
globals. C++ does. AFAIK compilers generally follow the language-
appropriate rules.

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

IMHO, the closest we have that is actually solid and understandable
is the basic DRF model, with undefined semantics for data races.
e.g. sections 2+3 from http://dl.acm.org/citation.cfm?id=1375581.1375591 .
This was never actually that expensive on x86, and it seems to be getting
more affordable on ARM as well. But my impression is that it'll never fly
on a GPU.

We know how to correctly add acquire/release atomics, though that
mixed model becomes far more complicated and unintuitive.

But almost everyone seems to feel the need to throw in some kind
of relaxed atomics or defined behavior for data races, at which point
things get flaky, and a universal design seems unlikely to me.

>
> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20170808/12ef50ec/attachment.html>


More information about the Concurrency-interest mailing list