Java Memory Model-Summary, java model Summary

Java Memory Model-Summary, java model Summary
Processor Memory Model

The sequential consistency memory model is a theoretical reference model. In the JMM and processor memory models, the sequential consistency memory model is usually used as a reference. The JMM and processor memory models relax the sequential consistency model during design, because if the processor and JMM are fully implemented according to the sequential consistency model, so many processors and Compiler Optimization will be disabled, which will have a great impact on the execution performance.

Based on the relaxation of the execution sequence of different types of read/write operations, you can divide the Memory Model of common processors into the following types:

Note: here, the processor's relaxation of read/write operations is based on the absence of data dependency between two operations (because the processor must follow the as-if-serial syntax, the processor does not re-sort two memory operations with data dependency ).

The following table shows the detailed features of the common processor memory model:

Memory Model name	Corresponding Processor	Store-Load re-sorting	Store-Store re-sorting	Load-Load and Load-Store re-sorting	Allows you to read data from other processors earlier.	Can read the current processor's write earlier
TSO	Sparc-TSOX64	Y				Y
PSO	Iscsi-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 re-sorting. The reason is described in Chapter 1: they all use the write cache, the write cache may cause the write-read operation to be reordered. At the same time, we can see that these processor memory models allow reading the current processor's write earlier, because the write cache is also because the write cache is only visible to the current processor, this feature allows the current processor to see the write temporarily saved in its own write cache before other processors.

The memory models of various processors in the table above, from top to bottom, have changed from strong to weak. The more performance-oriented processor, the weaker the memory model design. Because these processors want the memory model to be less bound to them, the better, so that 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 an appropriate position in the execution command sequence when generating bytecode to limit the re-sorting of the processor. At the same time, because the memory models of various processors are different in strength, in order to present a consistent Memory Model to programmers on different processor platforms, the number and type of memory barriers that JMM needs to insert in different processors are also different. Demonstrate the memory barrier to be inserted by JMM in memory models of different processors:

As shown in, JMM shields the differences between memory models of different processors and presents a consistent Memory Model for java programmers on different processor platforms.

Relationship between JMM, processor memory model and sequential consistency Memory Model

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

We can see that the four common processor memory models are weaker than the common three-language memory models, and the processor memory model and the language memory model are weaker than the sequential consistency memory model. Like the processor memory model, the more languages that pursue execution performance, the weaker the memory model design.

JMM Design

From the perspective of JMM designers, two key factors must be taken into account when designing JMM:

• The use of memory models by programmers. Programmers want the memory model to be easy to understand and 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, the better, so that they can be optimized as much as possible to improve performance. The compiler and processor want to implement a weak memory model.

Due to the conflict between the two factors, the core goal of the JSR-133 expert group in the design of JMM is to find a good balance: on the one hand to provide programmers with strong memory visibility guarantee; on the other hand, limits on compilers and processors should be relaxed as much as possible. Let's see how JSR-133 achieves this.

For details, see the sample code for calculating the circular area mentioned above:

double pi  = 3.14;    //Adouble r   = 1.0;     //Bdouble area = pi * r * r; //C  

 

The sample code for calculating the area of the circle above has three happens-before relationships:

Because of A happens-before B, the definition of happens-before requires that the result of operation A be visible to Operation B, and the execution sequence of operation A is prior to operation B. However, from the perspective of program semantics, re-sorting A and B will not change the execution result of the program, it can also improve the execution performance of the Program (allowing this type of re-sorting reduces the constraints on compiler and processor optimization ). That is to say, in the above three happens-before relationships, although 2 and 3 are required, 1 is unnecessary. Therefore, JMM divides the deduplication that happens-before requires to be disabled into the following two categories:

• Will change the re-sorting of program execution results.
• Does not change the re-sorting of program execution results.

JMM adopts different policies for the two different types of sorting:

• JMM requires the compiler and the processor to disable this type of re-sorting that will change the execution result of the program.
• For re-sorting that does not change the execution result of the program, JMM does not require the compiler and processor (JMM allows this re-sorting ).

The JMM design is as follows:

We can see two points:

• The happens-before rules provided by JMM to programmers can meet the needs of programmers. JMM's happens-before rules are not only easy to understand, but also provide programmers with sufficient memory visibility (some memory visibility guarantees do not necessarily actually exist, for example, A happens-before B above ).
• JMM has as few constraints on compilers and processors as possible. From the above analysis, we can see that JMM is actually following a basic principle: as long as the execution result of the program is not changed (it refers to a single-threaded program and a correctly synchronized multi-threaded Program ), you can optimize the compiler and processor. For example, if the compiler determines that a lock will only be accessed by a single thread after careful analysis, the lock can be eliminated. For example, if the compiler determines that a volatile variable is only accessed by a single thread after careful analysis, the compiler can treat this volatile variable as a common variable. These optimizations neither change the execution results of the program, nor increase the execution efficiency of the program.

JMM memory visibility guarantee

Java program memory visibility can be classified into the following three categories by program type:

Demonstrate the similarities and differences between the execution results of these three types of programs in JMM and in the sequential consistency Memory Model:

As long as the multi-threaded program is correctly synchronized, JMM ensures that the execution results of the program on any processor platform are consistent with the execution results of the program in the sequential consistency memory model.

JSR-133 patching of old memory model

The JSR-133 patches the old memory model before JDK 5 mainly in two ways:

• Enhance the memory semantics of volatile. The old memory model allows the volatile variables and common variables to be reordered. The JSR-133 strictly limits the reordering of volatile variables and common variables, so that volatile write-read and lock release-Get has the same memory semantics.
• Enhance the memory semantics of final. In the old memory model, the values of the same final variable may be different for multiple times. To this end, the JSR-133 adds two reordering rules for final. Now, final has initialization security.