[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 soon. Title: JMM9: Java Memory Model for JDK9 Author: Doug Lea [... other metadata omitted ...] Summary ------- 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. 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 JDK5 (JSR133). 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 (j...@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 Jaroslav Sevcı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 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 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.
