JEP 188: Java Memory Model Update

Summary

This JEP serves to provide information and guidance for efforts bearing on shared-memory concurrency, including those on Java SE 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 a major release. In particular, Java Language Specification (chapter 17) updates require such a JSR.

Motivation

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 Java SE 5 by JSR 133.

Description

Products of this JEP will be placed on the OpenJDK Wiki. The process will mainly take place on a dedicated OpenJDK mailing list. 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 "Java Memory Model Examples: Good, Bad and Ugly" by David Aspinall and Jaroslav Ševčík.)

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 Java SE 5, 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 forthcoming JEPs.

4. C11/C++11 compatibility. The C++11 and C11 standards adapted ideas from the JSR 133 JMM spec effort. However, they also extended them to cover constructs that have been (or may be) added to Java only after JSR 133 (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 platforms.

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

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

If this work fails to achieve its goals, then the current state of affairs will continue to hold.

Dependences

The JEP does not depend on any others. We anticipate that future JEPs related to concurrency will depend on this one.