JSR 133, which has been active for nearly three years, has recently issued its public recommendation on what to do about the Java Memory Model (JMM).
Tutorial Details:
Several serious flaws were found in the original JMM, resulting in some surprisingly difficult semantics for concepts that were supposed to be simple, like volatile, final, and synchronized. In this installment of Java theory and practice, Brian Goetz shows how the semantics of volatile and final will be strengthened in order to fix the JMM. Some of these changes have already been integrated in JDK 1.4; others are slated for inclusion in JDK 1.5. Share your thoughts on this article with the author and other readers in the accompanying discussion forum. (You can also click Discuss at the top or bottom of the article to access the forum.)
The Java platform has integrated threading and multiprocessing into the language to a much greater degree than most previous programming languages. The language\'s support for platform-independent concurrency and multithreading was ambitious and pioneering, and, perhaps not surprisingly, the problem was a bit harder than the Java architects originally thought. Underlying much of the confusion surrounding synchronization and thread safety are the non-intuitive subtleties of the Java Memory Model (JMM), originally specified in Chapter 17 of the Java Language Specification, and re-specified by JSR 133.
For example, not all multiprocessor systems exhibit cache coherency; if one processor has an updated value of a variable in its cache, but one which has not yet been flushed to main memory, other processors may not see that update. In the absence of cache coherency, two different processors may see two different values for the same location in memory. This may sound scary, but it is by design -- it is a means of obtaining higher performance and scalability -- but it places a burden on developers and compilers to create code that accommodates these issues.
What is a memory model, and why do I need one?
A memory model describes the relationship between variables in a program (instance fields, static fields, and array elements) and the low-level details of storing them to and retrieving them from memory in a real computer system. Objects are ultimately stored in memory, but the compiler, runtime, processor, or cache may take some liberties with the timing of moving values to or from a variable\'s assigned memory location. For example, a compiler may choose to optimize a loop index variable by storing it in a register, or the cache may delay flushing a new value of a variable to main memory until a more opportune time. All of these optimizations are to aid in higher performance, and are generally transparent to the user, but on multiprocessor systems, these complexities may sometimes show through.
Read
Tutorial at: Click here to view the tutorial
Rate Tutorial: Fixing the Java Memory Model, Part 1
View Tutorial: Fixing the Java Memory Model, Part 1
Related
Tutorials:
 Understanding Java Card 2.0 - JavaWorld March 1998
Understanding Java Card 2.0 - JavaWorld March 1998
|
Java Tip 79: Interact with garbage collector to avoid
memory leaks - JavaWorld
Java Tip 79: Interact with garbage collector to avoid
memory leaks - JavaWorld
|
Easy Java/XML integration with
JDOM, Part 1 - JavaWorld May 2000
Easy Java/XML integration with
JDOM, Part 1 - JavaWorld May 2000
|
Alternative deployment
methods, Part 3: The code - JavaWorld September
2000
Alternative deployment
methods, Part 3: The code - JavaWorld September
2000
|
Mapping XML to Java, Part 1 - JavaWorld August 2000
Mapping XML to Java, Part 1 - JavaWorld August 2000
|
Printing in
Java, Part 1 - JavaWorld October 2000
Printing in
Java, Part 1 - JavaWorld October 2000
|
C# : A language alternative or just J--? (part1)
C# : A language alternative or just J--? (part1)
|
Warning! Threading in
a multiprocessor world - JavaWorld February 2001
Warning! Threading in
a multiprocessor world - JavaWorld February 2001
|
Can double-checked locking be fixed? - JavaWorld May 2001
Can double-checked locking be fixed? - JavaWorld May 2001
|
Web services hits
the Java scene,
Part 1
Web services hits
the Java scene,
Part 1
|
Java security evolution
and concepts, Part 2
Java security evolution
and concepts, Part 2
|
Java scripting languages: Which is
right for you?
Java scripting languages: Which is
right for you?
|
Rumble in the
jungle: J2EE versus .Net, Part
1
Rumble in the
jungle: J2EE versus .Net, Part
1
|
Business process
automation
made easy with
Java, Part 1
Business process
automation
made easy with
Java, Part 1
|
Business process
automation
made easy with
Java, Part 2
Business process
automation
made easy with
Java, Part 2
|
Fixing the Java Memory Model, Part 2
Writing concurrent code is hard to begin with; the language should not make it any harder. While the Java platform included support for threading from the outset, including a cross-platform memory model that was intended to provide \"Write Once, Run Anywh
|
Fixing the Java Memory Model, Part 1
JSR 133, which has been active for nearly three years, has recently issued its public recommendation on what to do about the Java Memory Model (JMM).
|
Extensible Code Generation with Java, Part 1
Extensible Code Generation with Java, Part 1
Code generation is a key new trend in engineering, one that you need to understand well. The reason is simple: today's modern frameworks are extremely code-intensive. Using a code generator to build the code
|
Template-Based Code Generation with Apache Velocity, Part 2
Template-Based Code Generation with Apache Velocity, Part 2
As described in part one of this series, code generation typically uses a template engine to transform some kind of "model" into compilable code, given the formatting specified by a template.
|
Taming Tiger
Taming Tiger, Part 2
Understanding generics
Welcome to the second part of this three-part series on Sun Microsystems' latest release of the Java 2 Platform, Standard Edition (J2SE). To refresh your memory, Part 1 was a quick introduction to J2SE 1.5
|
|
|
|
