Open source Java proponents want to modernize the Java memory model, which has not been formally updated in more than nine years, and focus on concurrency.
A JEP (JDK Enhancement Proposal), number 188, dated this month, offers guidance on shared-memory concurrency efforts that impact Java SE (Standard Edition), JVM support, testing, and tools.
"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," the JEP document states. "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."
The JEP addresses these problems and extends coverage of the Java Memory Model, which was last revised for Java SE 5. That version of Java was released in September 2004, according to Wikipedia. The current release of Java SE is version 7, while release 8 is due in March.
The update will only indirectly improve concurrency support on multicore processors, said Doug Lea, organizer of the proposal. A memory model, he explained, presents the formal, mostly mathematically expressed rules on how threads interact with memory. All Java thread actions and synchronizations ultimately are specified in terms of the memory model.
"The main reason for updating is that over the past decade, some constructions have emerged that could not be specified using the JDK5 model; plus there are some known corner-case formal problems and unintended consequences that need to be addressed," Lea said. The model can be used to revise the Java language specification, improve implementations, support new concurrency features and develop new programming tools.
If successful, the JEP effort may lead to various enhancements, adjustments, and bug fixes 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 backward compatibility or on unrelated specifications or APIs," the proposal states. "If this work fails to achieve its goals, then the current state of affairs will continue to hold."
The proposal would feature improved formalization of the underlying memory model, in which the revised model would be mechanically checkable and more understandable. Existing errors would be addressed as well, and JVM coverage will be addressed along with C11/C++ compatibility and implementation guidance.
"Conformance to memory model requirements is difficult to test. We expect to work with engineers designing and implementing tests with clear bases in specifications," the proposal states. The reformulated model will be amenable to use by development tools that analytically check for errors like race conditions and maintenance of security properties across concurrent execution.
Lea served on the JCP (Java Community Process) executive committee, but left in 2010 after becoming disillusioned with the direction the JCP was taking. The memory model proposal is not a JCP effort, although the JCP may become involved with byproducts of the effort, Lea said.