Cache Coherence and the Java Memory Model
Can cache coherence affect the performance of a multithreaded Java application? Or does the virtual machine solve all the problems?
In which cases will the same multithreaded code work differently depending on the cache?
2 answers
In theory, for objects marked volatile, coherence should be provided independently of hardware support for cache coherence.
Most modern (SMP) computers have cache coherence built into their design. This is not the case (as far as I know) with HPC (high performance computing) clusters. I know that the JVM implementation promises Truly portable threads and synchronization model for them.
In general, problems with parallel threads are always on the programmer's conscience.
In general, JVM and the problem cache coherence are 2 completely different levels of interaction with the hardware of the computer. The problem cache coherence is always solved at the processor level, in 99% of cases it happens in hardware (in the Intel architecture, as far as I know, protocols are used for this MESIF and MOESI.).
The only thing that can really affect cache coherence is the performance of the application (for example, how it affects cache misses).
The theory suggests that the situation to avoid is putting multiple variables in a cache line and constant reads and writes between them. Obviously, this is bad, because the overhead of synchronizing caches will be quite large (of course, if this is not somehow optimized).
Practice also suggests that in Java it is unlikely to win on this.
Three levels JVM (code - bytecode-optimizing in native runtime code) weakly imply optimizations of this kind. If we were talking about C++, then we could still come up with something, and here, I assume that this is practically impossible, unless, of course, you use JNI.