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](https://jcp.org/en/jsr/detail?id=133).


Description
-----------

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.  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"](http://groups.inf.ed.ac.uk/request/jmmexamples.pdf) 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.