[jmm-dev] Now playing on the OpenJDK jmm-dev list

Doug Lea dl at cs.oswego.edu
Fri Feb 7 09:45:25 PST 2014

Here's the third, and I hope last, Intro post for this effort.

The goal of the OpenJDK Memory Model Update project
(http://openjdk.java.net/projects/jmm/) is to provide an updated Java
Memory Model, as described in JEP188
(http://openjdk.java.net/jeps/188). Probably, most results will be
posted on the OpenJDK Wiki
(https://wiki.openjdk.java.net/display/jmm/Main), for use in updating
JLS and as a reference for other JEPs producing associated software.

This mailing list is intended for developing an updated JMM, not for
usage questions etc about the JMM (for which
concurrency-interest at cs.oswego.edu and/or
javamemorymodel-discussion at cs.umd.edu may be more appropriate).  We
welcome participation by concurrency experts in formal specification,
hardware and software engineering, and software development tools.
Even though I'm listed as project lead, I hope never to have any
special role in development processes except for cat-herding efforts
to help direct attention to issues.

The idea of proposing JEP188 started with some informal exchanges that
grew to an unmanageable CC list upon proposal, so shifted to a
temporary mailing list while we waited for approval. There has already
been a fair amount of traffic (summarized below). Those on the
pre-jmm9 list should be auto-subscribed and receiving this as first
jmm-dev post.  To view pre-jmm9 mailing list echanges, see the mailman
archives (http://cs.oswego.edu/pipermail/pre-jmm9/), and for previous
CCed exchanges, see the gzipped mbox archive

Here's a brief summary of in-progress efforts (updated from 3 weeks
ago). Many of them are only loosely coupled with each other, so I've
been encouraging people to explore them concurrently.

1. Objectives.  These are not yet written all in one place, but I
think we are heading to rough agreement about core issues: safety
(including disallowing OOTA (out-of-thin-air) reads), security
(including information flow via indirection), global properties
(including SC (sequential consistency) for DRF (data race free)
programs solely using locks, and sometimes other cases), and
expressiveness (enabling finer-grained ordering control required to
implement known shared-memory concurrent algorithms).

2. Formalisms.  Several people/groups are contemplating different
approaches. This is still in early stages, but I'm optimistic
about prospects for something really good to emerge.

3. Mappings. How do models translate into compiler and processor rules
or actions? Or to JLS specs?

4. Experimentation, including: (1) Do compilers (mainly, optimizers)
and processors do what we think/hope? (2) What are performance impacts
of proposed mappings?

5. Initialization. Pending lots of details and checks, we might have
settled on a simpler path for this that amounts to ensuring release
fences at the ends of constructors in a way that introduces no (or at
most little) additional performance impact.

6. Expression of ordering constraints. There seems to be no substantive
disagreement with the idea of supplying C/C++11-like methods offering
manual ordering control via a compination of enhanced l-value
operations (".volatile") and fence methods. Many details needed.

7. Implementation guidance. We have already seen cases where exploring
alternatives has led to some possible improvements in JVMs. Probably
much more to come, sometimes in the form of contributing patches.

8. User/usage validation. Do the results of this effort help
developers?  We have a lot of known usages and complaints built up
over the years to draw on before needing to invite more.

9. Consequences. Not really started yet: Can we propose tools,
annotations, test suites, etc. Also User guidance docs.  (Aside: The
Android cross-language "SMP guide" might be a good model for some
audiences (http://developer.android.com/training/articles/smp.html).


More information about the jmm-dev mailing list