Theodora Fragkouli

About Theodora Fragkouli

Theodora has graduated from Computer Engineering and Informatics Department in the University of Patras. She also holds a Master degree in Economics from the National and Technical University of Athens. During her studies she has been involved with a large number of projects ranging from programming and software engineering to telecommunications, hardware design and analysis.

Java memory model is back

The Java memory model has been forgotten for more than nine years, but most open source Java supporters want to modernize it and focus on concurrency, as introduced in Java memory model takes small step toward modernization.

A JEP (JDK Enhancement Proposal), number 188, has come up this month, offering guidance on shared-memory concurrency efforts that impact Java SE (Standard Edition), JVM support, testing, and tools.

According to the JEP document, 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.

The JEP tries to solve the aforementioned problems. It also extends coverage of the Java memory model, which was last released with Java SE 5, in September 2004, which is pretty far from the current release of Java SE 7, and the new release of Java SE 8 that is coming in March.

As the author of the proposal, Doug Lea explains, the memory model 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 model can be used to revise the Java language specification, improve implementations, support new concurrency features and develop new programming tools.

If the JEP effort turns out to be successful, it 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. But no further impact on backward compatibility or on unrelated specifications or APIs is expected. On the other hand, if the effort 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.

According to the proposal, conformance to memory model requirements is difficult to test, so engineers that will design and implement tests with clear bases in specifications are expected. 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. Lea clarifies that the memory model proposal is not a JCP effort, although the JCP may become involved with byproducts of the effort.

Related Whitepaper:

Bulletproof Java Code: A Practical Strategy for Developing Functional, Reliable, and Secure Java Code

Use Java? If you do, you know that Java software can be used to drive application logic of Web services or Web applications. Perhaps you use it for desktop applications? Or, embedded devices? Whatever your use of Java code, functional errors are the enemy!

To combat this enemy, your team might already perform functional testing. Even so, you're taking significant risks if you have not yet implemented a comprehensive team-wide quality management strategy. Such a strategy alleviates reliability, security, and performance problems to ensure that your code is free of functionality errors.Read this article to learn about this simple four-step strategy that is proven to make Java code more reliable, more secure, and easier to maintain.

Get it Now!  

Leave a Reply


× 6 = eighteen



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.

Sign up for our Newsletter

20,709 insiders are already enjoying weekly updates and complimentary whitepapers! Join them now to gain exclusive access to the latest news in the Java world, as well as insights about Android, Scala, Groovy and other related technologies.

As an extra bonus, by joining you will get our brand new e-books, published by Java Code Geeks and their JCG partners for your reading pleasure! Enter your info and stay on top of things,

  • Fresh trends
  • Cases and examples
  • Research and insights
  • Two complimentary e-books