JVM re-sorting and JVM re-sorting

JVM re-sorting and JVM re-sorting

Reordering is usually a method used by the compiler or runtime environment to re-sort and execute commands to optimize program performance. There are two types of re-sorting: Re-sorting during compilation and re-sorting during runtime, which correspond to the compiling and runtime environments respectively.

In a concurrent program, the programmer pays special attention to data synchronization between different processes or threads, especially when multiple threads modify the same variable at the same time, reliable synchronization or other measures must be taken to ensure that data is correctly modified. An important principle here is: do not assume the order in which commands are executed, you cannot predict the order in which commands between different threads will be executed.

However, in a single-threaded program, it is usually easy to assume that the commands are executed sequentially. Otherwise, you can imagine what a terrible change will happen to the program. The ideal model is that the execution order of various commands is unique and ordered, which is the order in which they are written in the code, independent of the processor or other factors, this model is called the sequence consistency model and is also based on the von noriman system. Of course, this assumption is reasonable and rarely happens in practice. But in fact, no modern multi-processor architecture uses this model because it is too inefficient. In compilation optimization and CPU assembly line, commands are almost all involved in re-sorting.

Re-sorting during compilation

A typical example of re-sorting during compilation is to adjust the command sequence, minimize the number of reads and storage times of registers without changing the program semantics, and fully reuse the storage values of registers.

Assume that the First Command calculates A value assigned to variable A and stores it in the register. The second command has nothing to do with A but needs to occupy the Register (assuming that it will occupy the register where A is located ), the third instruction uses the value of A and has nothing to do with the second instruction. If A is in A sequential consistency model, A is put into A register after the first instruction is executed. When the Second instruction is executed, A no longer exists, and when the third instruction is executed, A is read into the register again, in this process, the value of A does not change. Generally, the compiler exchanges the positions of the second and third commands, so that when the first command ends, A exists in the Register, and then the value of A can be directly read from the register, reduces the overhead of repeated reads.

Significance of reordering for pipelines

Almost all modern CPUs use a pipeline mechanism to speed up instruction processing. Generally, a single instruction requires several CPU clock cycles for processing and is executed in parallel through the pipeline, several commands can be executed within the same clock period. Specifically, commands can be divided into different execution cycles, such as reading, addressing, parsing, and executing, and put them in different components for processing. At the same time, in the execution unit EU, functional units are divided into different components, such as addition components, multiplication elements, loading elements, and storage elements, different computing parallel execution can be further implemented.

The pipeline architecture determines that commands should be executed in parallel, rather than in the order model. Re-sorting is conducive to making full use of the pipeline and thus achieving the effect of exceeding the standards.

Ensure order

Although commands are not necessarily executed in the order we write, there is no doubt that in a single-threaded environment, the final effect of command execution should be consistent with that of sequential execution; otherwise, such optimization will be meaningless.

Generally, commands are reordered during the compilation or runtime to meet the above principles.

Sequencing in the Java Storage Model

In Java Memory Model (JMM), reordering is an important part, especially in concurrent programming. JMM uses the happens-before rule to ensure the ordered execution semantics. If you want the thread that executes operation B to observe the result of the thread that executes operation, then A and B must satisfy the happens-before principle. Otherwise, JVM can sort them in any order to improve program performance.

volatileKeyword can ensure the visibility of the variable, becausevolatileMain Memory is shared by all threads. The cost here is that it sacrifices performance and cannot use registers or caches because they are not global, visibility cannot be guaranteed, and dirty reads may occur.

volatileAnother function is to partially prevent the occurrence of reordering. The operation commands on volatile variables are not reordered, because the re-sorting may cause visibility problems.

In terms of visibility, locks (including explicit locks and Object locks) and read/write operations on atomic variables can ensure the visibility of variables. But the implementation method is slightly different. For example, the synchronization lock ensures that the data is re-read from the memory to refresh the cache when the lock is obtained. When the lock is released, the data is written back to the memory to ensure data visibility, while the volatile variable is simply read/write memory.