cpu-cache-and-numa git:20260903.f199530A

Immutable. This exact content never changes and is served at /api/v1/blob/4a64aa09679502cf.

---
name: cpu-cache-and-numa
description: >
  Hardware-aware Java: the cache line as the hardware's indivisible unit, false sharing and
  how it differs from lock contention, object layout measured with JOL, LongAdder versus
  AtomicLong, data locality in arrays and collections, and NUMA topology. Use when
  throughput gets **worse** as threads are added, when scaling efficiency collapses, when
  fields are being added to a class shared between threads, when volatile counters sit next
  to each other, when @Contended or padding is proposed, when -XX:+UseNUMA is being set, or
  when someone says a volatile write "flushes the cache". Does not cover happens-before
  correctness (java-memory-model), pool and queue sizing (littles-law-and-queueing), or
  kernel and cgroup behaviour (linux-for-jvm). Proving and fixing false sharing is
  false-sharing-and-contended, and topology and pinning is numa-and-cpu-affinity.
---

# CPU Cache and NUMA

## Purpose

Explain hardware-locality failures that blocking-oriented evidence can miss. False sharing
can degrade throughput without monitor contention or a dedicated JFR event, but cache misses,
coherence traffic, CPU saturation and scaling curves still leave evidence. Treat it as a
hypothesis to falsify, not the default explanation for poor scaling.

## Workflow

1. **Measure the scaling curve**: throughput, p99, CPU, allocation and synchronization from
   one thread through the production concurrency range. Efficiency is descriptive; there is
   no universal 0.5 entry threshold.
2. **Check the signature.** Throughput that worsens as writers are added is consistent with
   coherence, but also with locks, queueing, GC, bandwidth saturation, scheduler overhead or
   a downstream limit. Use competing hypotheses.
3. **Rule out lock contention and true sharing first** — see the distinction table in
   `references/false-sharing.md`. Locks appear in JFR; false sharing appears nowhere.
4. **Prove the layout with JOL**, never with mental arithmetic.
5. **Measure coherence on supported hardware.** Prefer `perf c2c`, HITM/cache-to-cache or
   vendor PMU events when available; LLC misses alone do not prove false sharing. Normalize
   against the application's own baseline and retain event support/scaling warnings.
6. **Validate twice.** Use JMH to isolate the proposed mechanism, then an application/load
   test at the same topology and concurrency to prove the production effect.

## Rules

- A cache line is 64 bytes on x86-64 but **128 on Apple Silicon and POWER**. Verify rather
  than assume; the value determines all padding arithmetic.
- A write must obtain coherent ownership of the line and invalidates other cached shared
  copies when present. Repeated ownership transfer between writers to independent fields is
  false sharing; a write to a line already held exclusively need not broadcast the same work.
- **The JMM does not specify cache flushes, MESI or store-buffer draining.** A volatile write
  has release/order and visibility semantics; a volatile read has acquire semantics. HotSpot
  maps those guarantees differently by architecture. Hardware coherence can serve a valid
  cached copy, but do not present one x86 implementation sequence as the Java contract.
- Do not compute offsets in your head — run JOL on the target JDK, VM mode and class
  hierarchy. HotSpot field packing, headers, inheritance gaps, compressed pointers and
  alignment are implementation details; even familiar 12-byte-header examples are not a
  layout contract.
- Compact Object Headers gives an 8-byte header: product in JDK 25 behind
  `-XX:+UseCompactObjectHeaders` (JEP 519), **off by default through JDK 26 and on by
  default from JDK 27** (JEP 534). It shifts every offset — and by packing more fields per
  line it can **worsen** false sharing while improving footprint.
- `-XX:+CompactFields` does not exist on the baseline (obsolete in 15, expired in 16), and
  `-XX:-UseEmptySlotsInSupers` was removed in 23. The JDK 15+ layout is the only one.
- The GC moves objects and the default alignment is 8 bytes, not 64. Any optimisation based
  on an absolute address is undone by the first compaction; only padding **inside** the
  object is stable. A moving collector may change the absolute address, and internal padding
  still needs enough separation for possible line alignment/straddling.
- HotSpot's default contended padding width is commonly 128 bytes, intended to isolate beyond
  one typical line and reduce adjacent-line effects; verify the flag/build rather than
  treating the rationale or width as a specification. In application code it needs `--add-exports` **and**
  `-XX:-RestrictContended`; without the second it is silently ignored.
- Prefer `LongAdder` for highly contended statistics only when a non-atomic `sum()` snapshot
  is acceptable. `AtomicLong` provides linearizable updates/reads and can win at low
  contention; padding protects independent fields. These solve different contracts and must
  not be ordered as universal alternatives.
- Move metrics out of hot state objects rather than padding them. It resolves the conflict
  **and** improves cache density of the hot state.
- In Java, `Particle[]` is **not** contiguous — the array holds references, and the objects
  are scattered. The array-of-objects problem here is indirection, not wasted bandwidth, and
  carrying over `sizeof(struct)` reasoning from C leads to the wrong conclusion. Prefer
  primitive arrays where possible.
- Local and remote DRAM latency/bandwidth depend on CPU generation, topology, frequency,
  access pattern and contention. Measure with a topology-aware benchmark and hardware
  counters; published nanoseconds are orientation, not a production model.
- `-XX:+UseNUMA` governs supported Parallel GC and G1 allocation policies (G1 since JDK 14,
  Linux). ZGC has separate, evolving NUMA-aware allocation/relocation behavior not controlled
  by this flag. CPU confinement changes visible topology; verify the target JDK's logs/source
  and measured page placement rather than assuming one collector's semantics for another.

## References

- [False sharing](references/false-sharing.md) — the distinction from lock contention, the
  detection procedure, JOL usage and the correction options. Read when scaling efficiency is
  poor or when adding fields to a shared class.
- [NUMA](references/numa.md) — verifying topology, reading `numastat`, and choosing between
  distributing and pinning. Read only after confirming more than one NUMA node exists.