Detect and resolve false sharing in Java on Arm Neoverse
Introduction
Understand false sharing in Java
Create and inspect the baseline
Identify the contended cache line
Add @Contended and verify contention padding
Compare baseline and padded runtimes
Next steps
Detect and resolve false sharing in Java on Arm Neoverse
Who is this for?
Java developers who need to understand sub-optimal multithreaded scaling caused by cache-line contention on multi-core Arm servers.
What will you learn?
After completing this Learning Path, you'll be able to perform the following tasks:
- Identify why independent Java fields or objects can contend for one cache line.
- Inspect adjacent Java fields with Java Object Layout (JOL) and record their sharing with Perf C2C.
- Identify a highly contended cache line in Perf C2C output.
- Apply @Contended, verify the padded layout, and compare repeated runtimes.
Prerequisites
Before starting, you'll need the following prerequisites:
- Access to an Arm Neoverse-based Linux system with Arm Statistical Profiling Extension (SPE) enabled and exposed to Perf
- Familiarity with compiling and running Java applications
- Permission to use Perf on the target system
Summary
This summary was drafted with an approved AI-assisted workflow and reviewed by Arm contributors before publication. Human technical review remains part of the process so the final page reflects engineering rigor, accuracy, and Arm editorial standards.
You’ll detect and mitigate Java false sharing on Arm Neoverse with JOL, Perf C2C, SPE, and HotSpot’s
@Contended padding. First, you’ll learn how independent fields can contend for one cache line. Then, you’ll build the baseline, inspect its layout, and record it. Next, you’ll identify the highest-ranked shared line, add padding, and compare the reports. Finally, you’ll collect repeated timing pairs to assess runtime impact and measurement variability.Frequently asked questions
These FAQs were drafted with an approved AI-assisted workflow and reviewed by Arm contributors before publication. Human technical review remains part of the process so the final page reflects engineering rigor, accuracy, and Arm editorial standards.
Run the
/sys/bus/event_source/devices check from the profiling instructions and confirm that it lists at least one SPE performance monitoring unit, usually arm_spe_0. If you get no output, follow the
SPE enablement instructions
and repeat the check before you run perf c2c record.Resolve the absolute path to the Java executable and derive the matching
javac from the same Java Development Kit (JDK). Use the same terminal so that compiler and runtime versions stay consistent across steps.Confirm that the report is sorted by
Peer Snoop, then inspect the line with the largest absolute peer-snoop count. Look for accesses from two or more CPUs, repeated loads and stores at offsets within the line, and activity while left-writer and right-writer run. Treat the line as a candidate because Perf C2C alone can’t prove that its address belongs to BaselineCounters.Compile with the required package export, and run the padded mode and JOL with
-XX:-RestrictContended. In the JOL output, verify that padding separates left and right into different contention groups. Keep -XX:-RestrictContended on every padded run because HotSpot otherwise ignores this application annotation.Expect the padded mode to show lower absolute peer-hit counts and often a lower median worker-phase runtime than the baseline. Don’t expect the representative values to match your system. Collect several alternating pairs, compare their medians, and examine variability before you conclude that padding helped. Also weigh any runtime improvement against the larger object size.