Java Memory Model-summary

Processor memory model

The sequential consistent memory model is a theoretical reference model, and the JMM and processor memory models typically refer to sequential consistent memory models at design time. The JMM and processor memory models are designed to relax the sequential consistency model, because if the processor and the JMM are implemented exactly as sequential conformance models, many processor and compiler optimizations are banned, which can have a significant impact on performance.

Based on the relaxation of the order of execution of different types of read/write operations, the memory model of the common processor can be divided into the following types:

1. The sequence of write-read operations in the unwind program, resulting in the total store ordering memory model (TSO).
2. On the basis of the previous 1, the order of write-write operations in the program continues to be relaxed, resulting in the partial store order memory model (called PSO).
3. On the basis of the preceding 1 and 2, the sequence of read-write and read-read operations in the program continues to be relaxed, resulting in the relaxed memory order (RMO) and PowerPC memory models.

Note that the processor's relaxation of read/write operations is premised on the absence of data dependencies between two operations (because the processor adheres to the as-if-serial semantics, the processor does not reorder the two memory operations that have data dependencies).

The following table shows the details of the common processor memory model:

Memory model Name	The corresponding processor	Store-load reordering	Store-store reordering	Load-load and Load-store reordering	Write to other processors can be read earlier.	Writes to the current processor can be read earlier
TSO	Sparc-tsox64	Y				Y
Pso	Sparc-pso	Y	Y			Y
Rmo	Ia64	Y	Y	Y		Y
Powerpc	Powerpc	Y	Y	Y	Y	Y

In this table, we can see that all processor memory models allow write-read reordering, as explained in the first chapter: they all use write buffers, and write buffers may cause write-read operations to be reordered. At the same time, we can see that these processor memory models allow more morning reading to the current processor's write because of the write buffer: Because the write buffer is only visible to the current processor, this feature causes the current processor to see a write that is temporarily saved in its own write buffer than the other processors.

The various processor memory models in the table above, from top to bottom, are strongly weakened by the model. The more performance-seeking processors, the weaker the memory model design will be. Because these processors want the memory model to be less bound to them, they can do as much optimization as possible to improve performance.

Because the common processor memory model is weaker than JMM, the Java compiler inserts a memory barrier at the appropriate location in the execution instruction sequence to limit processor reordering when generating bytecode. At the same time, because the different processor memory models are not the same strength, in order to present a consistent memory model to programmers on various processor platforms, JMM the number and variety of memory barriers that need to be inserted into different processors. Shows the memory barriers that JMM need to insert in different processor memory models:

As shown, JMM masks differences in the different processor memory models, which present a consistent memory model for Java programmers on different processor platforms.

JMM, the relationship between the processor memory model and the sequential consistent memory model

JMM is a language-level memory model, the processor memory model is a hardware-level memory model, and the sequential consistent memory model is a theoretical reference model. The following is a comparison of the language memory model, the processor memory model, and the sequential consistent memory model:

As we can see, the common 4 processor memory models are weaker than the usual 3 language memory models, and both the processor memory model and the language memory model are weaker than the sequential consistent memory model. As with processor memory models, the more you pursue performance-based languages, the weaker the memory-model design will be.

The design of JMM

From the JMM designer's point of view, there are two key factors to consider when designing a JMM:

• The use of memory models by programmers. Programmers want the memory model to be easy to understand and easy to program. Programmers want to write code based on a strong memory model.
• The implementation of the memory model by the compiler and processor. The compiler and the processor want the memory model to be less bound to them, so they can do as much optimization as possible to improve performance. The compiler and the processor want to implement a weak memory model.

Since these two factors contradict each other, the core goal of the JSR-133 Expert Group in designing the JMM is to find a good balance: to provide sufficient memory visibility for the programmer, and, on the other hand, to be as relaxed as possible about the limitations of compilers and processors. Let's take a look at how JSR-133 is achieving this goal.

For specific instructions, see the example code for calculating the circle area as mentioned earlier:

double pi  = 3.14;    // A double R   = 1.0;     // B Double // C  

The example code above that calculates the area of a circle has three happens-before relationships:

1. A Happens-before B;
2. B Happens-before C;
3. A Happens-before C;

Because the definition of a happens-before b,happens-before requires that the result of a operation execution be visible to B, and the order of execution of a operation is preceded by the B operation. But from the point of view of program semantics, reordering A and B does not change the execution result of the program, but also improves the execution performance of the program (allowing this reordering to reduce the constraints of compiler and processor optimizations). In other words, the above 3 happens-before relationships, although 2 and 3 are required, but 1 is unnecessary. As a result, JMM the reordering of Happens-before requirements into the following two categories:

• Will change the reordering of the results of the program execution.
• Does not change the reordering of the results of the program execution.

JMM has adopted different strategies for reordering these two different properties:

• For reordering that alters the execution of the program, JMM requires that the compiler and processor must disallow this reordering.
• JMM does not require the compiler and processor to reorder the results of the program execution (JMM allows this reordering).

Here is the design of JMM:

It can be seen from two points:

• JMM provides programmers with the Happens-before rules to meet the needs of programmers. JMM's Happens-before rules are easy to understand and provide programmers with sufficient memory visibility guarantees (some memory visibility guarantees are not necessarily real, such as a happens-before B above).
• JMM the compiler and processor are as small as possible. From the above analysis, we can see that JMM is actually following a basic principle: as long as the execution of the program does not change the results (refers to the single-threaded programs and the correct synchronization of multithreaded procedures), compiler and processor how to optimize the line. For example, if the compiler after careful analysis, that a lock will only be accessed by a single thread, then this lock can be eliminated. For example, if the compiler after careful analysis, that a volatile variable will only be accessed by a single thread, then the compiler can treat this volatile variable as a common variable. These optimizations will not change the execution result of the program, but also can improve the execution efficiency of the program.

JMM's Memory Visibility guarantee

The memory visibility of Java programs is guaranteed to be divided into the following three categories by program type:

1. Single threaded. There is no memory visibility issue with single threaded threads. The compiler, runtime, and processor will work together to ensure that the results of a single-threaded program are the same as the execution of the procedure in the sequential consistency model.
2. A multithreaded program that synchronizes correctly. The execution of multithreaded programs that are correctly synchronized will have sequential consistency (the execution result of the program is the same as that of the program in the sequential-consistent memory model). This is the focus of JMM attention, JMM provides the programmer with a memory visibility guarantee by restricting the reordering of compilers and processors.
3. multithreaded programs that are not synchronized/not synchronized correctly. JMM provides them with minimal security: The value read when the thread executes, either the value written by a previous thread or the default value (0,null,false).

Shows the similarities and differences between the three types of programs in JMM and the execution results in the sequential consistent memory model:

As long as multithreaded programs are synchronized correctly, JMM guarantees that the program executes on any processor platform, consistent with the execution of the program in the sequential consistent memory model.

JSR-133 patching of old memory models

JSR-133 's patching of the old memory model before JDK5 is mainly two:

• Enhance the memory semantics of volatile. The old memory model allows volatile variables to be re-ordered with ordinary variables. JSR-133 strictly restricts the reordering of volatile variables and ordinary variables, so that volatile write-read and lock-release-fetches have the same memory semantics.
• Enhances final memory semantics. In the old memory model, the value of reading the same final variable multiple times may be different. To do this, JSR-133 added two reordering rules for final. Now, final has initialization security.

Java Memory Model-summary