False sharing in a multi-threaded Java application

JRE allows you to abstract from a specific platform, making writing cross-platform code much easier. Of course, the Write once, run anywhere does not reach the ideal, but life makes it much easier.

With the abundance of frameworks and the fullness of its own standard library, the idea that the program runs on a very specific hardware gradually fades into the background. In most cases, this is justified, but sometimes life makes its own adjustments.

The vast majority of modern processors have a cache for storing frequently used data. Cache memory is divided into blocks (Cache line). Mechanisms implementing Cache coherence ensure cache synchronization between the processor cores (s) in a computer system.
')
The term false sharing means access to different objects in a program that share the same block of cache memory. False sharing in a multi-threaded application, when variables are modified from different streams in one block, leads to a decrease in performance and an increase in the load on Cache coherence mechanisms. Details on how this happens can be found in the article on this topic.

Tools

• hsdis plugun for disassembling jit code.
• Intel® VTune ™ Amplifier XE 2013 for profiling and CPU metering.

Example

The multithreaded application, the threads, at each iteration, take the previous value from their common array cell, perform calculations and add the results back.

Check that jvm didn’t make any unnecessary optimizations:

 java -XX:+UnlockDiagnosticVMOptions -XX:CompileCommand=print,SArray$MThread::run -XX:PrintAssemblyOptions=intel -cp target\falseshare-1.0-SNAPSHOT.jar SArray 

If globalArray is not volatile, then jvm will not read from memory every time:

In real life, when the computational method is not trivial, such optimization may not happen.

In this case, volatile is used solely to confuse the optimizer. A record of the volatile long [] array type means that the volatile semantics refers to a pointer to an array, and not to its elements.

Create a new project in VTune Amplifier:

We create and run Generic Exploration analysis. In summary we see:

CPI - 2.100, with normal for settlement tasks 1 and less. Go to the view Hardware issues:

There is Contested access, meaning that the data written by one stream is read by another thread and at the same time the threads run on different cores / CPUs.
That is, the cells of the globalArray array fall into one cache line.

In order to avoid this situation, we will space the cells in memory by the cache line value. On the Intel i5, the cache line size is 64 bytes. Change the line

  threads[i] = new Thread(new MThread(ITERATIONS, i)); 

on

  threads[i] = new Thread(new MThread(ITERATIONS, (i + 1) * 8)); 

Why not i * 8? Because in the case of arrays, the first element after the title of the object is the length (field length). For element access operations, jvm can read this field to check the validity of the index.
We launch the repeated analysis in Vtune:

CPI - 0.586, Contested access is gone, In proportion to CPI, the operating time has changed, from 13.7 to 4.5 seconds.
Testing was conducted on a single-processor machine, in the case of a multiprocessor configuration, the overhead of synchronizing the cache memory will be even greater.

Naturally, the same problem may arise when accessing the fields of objects. But since the minimum size of the object (c one field) in the hostpot jvm is 16 bytes, the problem will be less common. The way to avoid false sharing for objects using inheritance can be viewed in the jmh source, in the BlackHole implementation. As one of the options - not to create bulk objects for all threads, but to spread this process over time.

Testing was conducted on a machine with an Intel Core i5 3.3 GHz processor, 64bit JDK 1.7.0_21, Intel Vtune Amplifier XE 2013 Update 11 (build 300544) Evaluation license, Windows 7 64bit.

Ps. Do not take the performance figures given in the article literally. The results will depend to a large extent on external factors, for example, on how the OS, together with jvm, distributes the threads among the processor cores (s). But if something is created high-performance, then such features of target platforms should be taken into account.