JMM9 Project (Java Memory Model revisions for JDK9)
dl at cs.oswego.edu
Wed Jan 8 21:28:24 UTC 2014
[to hotspot-dev, cross-post to core-libs-dev]
We are proposing the creation of the JMM9 Project with Doug Lea as
the Lead and Hotspot as the sponsoring Group.
JMM9 is unusual as a Project in that it will not produce software,
so there is no suggested initial list of Authors.
The sponsoring Group is also somewhat arbitrary, but Hotspot
seems most directly impacted. The main participants include academics
and researchers expert in the formal specification of shared-memory
concurrency, along with hardware and software engineers. The tentative
participants are already making progress on identifying problems and
solutions in ad-hoc discussions, so would be grateful to have an
approved home base and mailing list to continue on.
I expect that the Hotspot group lead will send out a Call For Votes
shortly. For now, here is a paste of the JMM9 JEP that might be posted
Title: JMM9: Java Memory Model for JDK9
Author: Doug Lea
[... other metadata omitted ...]
This JEP serves to provide information and guidance for JDK9-related
efforts bearing on shared-memory concurrency, including those on
specification updates, JVM concurrency support, JDK components,
testing, and tools. Engineering and release efforts in these areas
will be subject to other JEPs, that will in turn become components of
one or more JSRs targetted for JDK9. In particular, JLS (chapter 17)
updates require such a JSR.
Specifying shared memory consistency models, and developing and
maintaining features and components that operate in accord with them,
are among the most central yet difficult issues in engineering
concurrent and parallel platforms. Specification limitations, errors,
and unintended consequences become apparent over time; new hardware
platforms, programming techniques, and software components and tools
emerge that escape existing boundaries. This JEP addresses problems
and extends coverage of the Java Memory Model (JMM), last revised for
Products of this JEP will be placed on the OpenJDK Wiki
(https://wiki.openjdk.java.net/). The process will mainly take place
on a dedicated openjdk mailing list (jmm9 at openjdk.java.net). We
expect results to include the following:
1. Improved formalization. Parts of the underlying model will be
reformulated. We aim for the revised model to be mechanically
checkable, as well as more readily humanly understandable. When
phrased in terms of JLS chapter 17 updates, this will also address
existing errors pointed out in a number of academic papers. (For the
earliest, see http://groups.inf.ed.ac.uk/request/jmmexamples.pdf "Java
Memory Model Examples: Good, Bad and Ugly" by David Aspinall and
2. JVM coverage. Existing specifications focus on language-level
constructs. This leaves some issues (for example initialization)
incompletely defined, especially for other languages running on
JVMs. These will be addressed, possibly by basing a core model on a
minimal set of byte codes and intrinsics.
3. Extended scope. Existing specifications explicitly cover Java
Threads, locks, monitors, and volatile and final fields. However,
since JDK5, features have been added that cannot be rigorously
specified in these terms (for example, AtomicX.weakCompareAndSet).
These must be addressed. We also anticipate that further extensions
may arise in the course of other JDK9 JEPs; possibly including forms
of Atomics that can be embedded into other objects.
4. C11/C++11 compatibility. The C++11 and C11 standards adapted ideas
from the JSR133 JMM spec effort. However, they also extended them to
cover constructs that have been (or may be) added to Java only after
JSR133 (see above). In part because Java programs may call C native
libraries, it should be the case that equivalent constructs have
compatible specifications across languages. We will further explore
whether cross-language conventions can be established to ensure that
low-level implementations of these constructs are compatible on common
5. Implementation guidance. JVM implementors, JDK library developers,
and developers as a whole often find it useful to rely on documents
explaining how the JMM impacts particular problems and solutions. We
intend to provide such documents.
6. Testing support. Conformance to memory model requirements is
difficult to test. We expect to work with engineers designing and
implementing tests with clear bases in specifications.
7. Tool support. The reformulated model will be amenable for use by
software development tools that analytically check for errors such as
race conditions, as well as those checking that security properties
hold across concurrent execution. While design and construction of
tools themselves are out of scope, this JEP may contribute guidelines
for annotations that would enable high quality static and dynamic
Risks and Assumptions
Success requires contributions by concurrency experts in formal
specification, hardware and software engineering, and software
development tools. We have pre-arranged a core of expertise by
obtaining tentative agreements to participate by academics,
researchers, and engineers with extensive experience and knowledge in
these areas. We will continue to encourage other experts to
participate as well.
If successful, we expect that this effort may lead to various
enhancements, adjustments, and bugfixes across the platform. It is
also possible that some uncommon borderline programming constructions
will be shown to be problematic. However, we do not expect any further
impact on backwards compatibility, or on unrelated specifications or
If this work fails to achieve its goals, then the current state of
affairs will continue to hold.
The JEP does not depend on any others. We anticipate that
future JEPs related to concurrency will depend on this one.
More information about the core-libs-dev