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:

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

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.

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.

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.

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.

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.

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.