# Are volatile reads really free?

DevFeed: [Are volatile reads really free?](<https://devfeed.tech/articles/are-volatile-reads-really-free-12444.md>)

Original publisher: [Read original article](<http://brooker.co.za/blog/2012/09/10/volatile.html>)

Author: Marc Brooker

Published: 2012-09-10T00:00:00Z

Content type: article

Language: en

Sources: [Marc Brooker's Blog](<https://devfeed.tech/sources/marc-brooker-s-blog.md>), [Marc Brooker's Blog](<https://devfeed.tech/sources/marc-brooker-s-blog-2.md>)

Topics: [JIT](<https://devfeed.tech/topics/jit.md>), [Assembly](<https://devfeed.tech/topics/assembly.md>), [Compiler](<https://devfeed.tech/topics/compiler.md>), [intel](<https://devfeed.tech/topics/intel.md>)

Tags: [assembly](<https://devfeed.tech/tags/assembly.md>), [code](<https://devfeed.tech/tags/code.md>), [command-line](<https://devfeed.tech/tags/command-line.md>), [compiler](<https://devfeed.tech/tags/compiler.md>), [java](<https://devfeed.tech/tags/java.md>), [jit](<https://devfeed.tech/tags/jit.md>), [x86](<https://devfeed.tech/tags/x86.md>)

## AI overview

The article examines whether reads from Java volatile variables are genuinely free on x86. It explains how JSR-133 memory barriers map to x86 operations and checks the behavior of Java JRE 1.6 by inspecting JIT-generated assembly. The generated code follows the specification, with a lock addl instruction used as the StoreLoad barrier.

## Source excerpt

Are volatile reads really free? Some claim that reads from volatile variables are free in Java on x86. Is that claim true? There is a somewhat common belief among Java programmers that reads from volatile variables are free. Are volatile variable 'reads' as fast as normal reads? from StackOverflow is a perfect example, because it's the top result I get from Google for most related searches. The top answer says: On an x86, there is no additional overhead associated with volatile reads. and goes on to say: JSR-133 classifies four barriers "LoadLoad, LoadStore, StoreLoad, and StoreStore". Depending on the architecture, some of these barriers correspond to a "no-op", meaning no action is taken, others require a fence. There is no implicit cost associated with the Load itself, though one may be incurred if a fence is in place. In the case of the x86, only a StoreLoad barrier results in a fence. Reading Doug Lea's The JSR-133 Cookbook for Compiler Writers gives the same impression. It says: Issue a StoreStore barrier before each volatile store. and Issue a StoreLoad barrier after each volatile store. Note that you could instead issue one before each volatile load, but this would be slower for typical programs using volatiles in which reads greatly outnumber writes. Alternatively, if available, you can implement volatile store as an atomic instruction (for example XCHG on x86) and omit the barrier. This may be more efficient if atomic instructions are cheaper than StoreLoad barriers. and Issue LoadLoad and LoadStore barriers after each volatile load. Doug lists the StoreStore, LoadLoad and LoadStore barriers as noops on x86. It makes some sense to read this as a validation of the idea that volatile reads are free. No extra instructions are issued for the reads, and instructions are what makes computers take time, so no more time is taken. Right? The first step to answering that question is seeing if the Java JRE 1.6 actually behaves like Doug says it should. Possibly the e