A Java field declared volatile is read many times inside a hot loop and written only rarely. Break down what that ordered access actually costs the running JVM, and say which part of the cost usually dominates in a real profile.

## "Ordered access is expensive" is three different costs When a Java field is declared `volatile` (or accessed through a `VarHandle` with an ordered access mode), engineers usually say "that costs a barrier" and stop. On a field that is read constantly and written rarely, the emitted barrier is frequently the smallest of three independent costs. Naming all three, and knowing which one a given profile is showing, is the whole skill here. ## Cost 1: the fences the JVM emits, which is a per-architecture number Java since 9 exposes a ladder of access modes through `VarHandle`: plain, opaque, acquire/release, and volatile, in increasing ordering strength. Each mode compiles to some combination of hardware ordering instructions, and the compiled cost is not a property of the mode alone but of the mode *and the target ISA*. On x86-64 the hardware already provides load-load, load-store and store-store ordering, so an ordered *read* needs no extra instruction; the cost sits on the *write* side, where the store buffer must be drained before subsequent loads may proceed. On AArch64 the split is different: a load-acquire is a genuine instruction with a genuine cost, while a release store is comparatively cheap. (Precisely which fences HotSpot emits around a volatile read and a volatile write on each architecture is covered separately; the point for costing is only that the number is asymmetric and does not transfer between architectures.) The practical consequence for a read-mostly field: whatever the write side costs, it is amortized over an enormous number of reads. Optimizing that term is usually optimizing the wrong one. ## Cost 2: the optimizations the JIT is no longer permitted to perform This is the term people miss, and it is usually the largest for hot reads. An ordered access constrains the *compiler* as well as the processor, and C2's loop optimizations are exactly the ones it constrains. **Register promotion is blocked.** For a plain field, C2 can prove nothing else in the loop writes it, load it once into a register, and use the register for every iteration. An ordered read must actually observe memory each time it executes, so the value cannot live in a register across iterations. A loop that reads the field ten times per iteration issues ten loads per iteration, forever. **Redundant-read elimination and common-subexpression elimination are blocked.** Two plain reads of the same field with no intervening write collapse into one. Two ordered reads may legally return different values (another thread may have written between them), so they cannot be collapsed, and expressions derived from them cannot be shared. **Loop transforms including vectorization are blocked.** Superword/vectorization requires the compiler to reorder and batch memory operations across iterations. An ordered access is a scheduling barrier inside the loop body, so unrolling and vectorization of the surrounding array work commonly fail to apply. The visible symptom is a loop that runs several times slower than an equivalent loop over plain data, with no fence stall anywhere in the profile. **The read-once-into-local pattern.** If the algorithm is happy with a single consistent snapshot per call or per loop, copying the field into a local variable before the loop removes every one of these losses. One ordered read happens, with full ordering semantics and full visibility for the values it publishes; the loop body then reads a local and optimizes exactly like plain code. Crucially, this does not weaken the field for anyone: other threads still see a `volatile` field with unchanged guarantees; only this thread's reading frequency changed. It is the highest-yield, lowest-risk move available, and it is why "the volatile is slow" so often turns out to be "the loop re-reads it." ## Cost 3: coherence traffic, and telling it apart from fence cost The third cost has nothing to do with ordering strength at all. Cache coherence works per cache line. When one core writes the line, every other core's copy is invalidated, and each of their next reads is a coherence miss served from a remote cache or memory. A field that is written even occasionally while dozens of cores read it can therefore be an order of magnitude more expensive than any fence. False sharing is the same mechanism with none of the sharing: an unrelated counter that happens to sit on the same 64-byte line produces identical invalidations. In a real Java profile the three look different. Fence cost shows as time attributed to the volatile store instruction itself. Blocked JIT optimization shows as *instruction count*: the same method with many more loads and no vector instructions, visible by comparing the compiled assembly or the profile's cycles-per-iteration against a plain-field variant. Coherence traffic shows as last-level cache misses and memory stalls on the load, spread across all the reading threads rather than concentrated on the writer. `@Contended` padding, per-thread or per-stripe sharding with aggregation on read, and simply writing less often (batching, sampling, write-on-change) address that cost; changing the access mode does not. ## Putting them together For the read-mostly hot field in the question, the ranking is usually: blocked JIT optimization first, coherence traffic second when the write rate or the reader count is high, emitted fences last. That ordering is why the productive interventions are structural, reading once into a local and fixing layout, rather than reaching down the access-mode ladder.