---
title: "Performance impact of Alignment"
url: https://daily.dev/posts/performance-impact-of-alignment-i36nfpbhb
source_url: https://eme64.github.io/blog/2026/01/12/Alignment-Performance.html
type: article
source: "Awesome Java Newsletter"
published: 2026-08-13T20:45:50.697Z
updated: 2026-08-13T20:56:38.353Z
tags: ["performance", "java", "jvm"]
reading_time: 15
upvotes: 1
comments: 0
language: en
---

> ## Documentation Index
> Fetch the complete documentation index at: https://daily.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Performance impact of Alignment

**[Awesome Java Newsletter](https://daily.dev/sources/java_libhunt)** · 15 min read · 1 upvotes · 0 comments

## Summary

Memory alignment significantly affects SIMD vectorization performance, both for auto-vectorization and Java's Vector API. Benchmarks on x64 AVX512 and Aarch64 NEON machines show that misaligned loads/stores that cross cacheline boundaries get split into two memory accesses, causing slowdowns of up to 100% for large 64-byte vectors, while smaller vectors see smaller impacts (around 10-20%). Aligning stores tends to matter more than aligning loads on x64. In the C2 auto-vectorizer, accidentally aligning loads instead of stores caused a 20% performance regression. With the Vector API, alignment is the developer's responsibility since JDK26 gives no way to query array alignment; off-heap MemorySegments allocated with explicit alignment (e.g., 64-byte cacheline) guarantee aligned access, while heap arrays have unpredictable alignment that gets worse with compact object headers enabled. Despite this, vectorization is usually profitable even without perfect alignment.

## Full article

daily.dev links to this article rather than hosting it. Read it at the original source: <https://eme64.github.io/blog/2026/01/12/Alignment-Performance.html>

## Questions this post answers

### Why did aligning loads instead of stores cause a performance regression in the auto-vectorizer?

On x64 machines, the performance penalty for misaligned stores is much worse than for misaligned loads, so the C2 auto-vectorizer should prefer aligning stores over loads when it can only guarantee alignment for one access. An accidental swap to aligning loads rather than stores caused a 20% performance regression, since store misalignment costs more than load misalignment.

_daily.dev surfaces JVM performance writeups like this for engineers chasing down vectorization regressions._

### Does compact object headers in JDK affect SIMD vector alignment on Java arrays?

Yes, enabling -XX:+UseCompactObjectHeaders changes the array header offset to the 0th element from 16 bytes to 12 bytes, shifting it 4 bytes off the standard 8-byte alignment boundary. This means vector accesses on such arrays never achieve cacheline alignment, resulting in consistently slower performance compared to the default header layout.

_track JVM flag trade-offs like this on daily.dev before tuning vectorized workloads._

### How much performance difference does memory alignment make for SIMD vector loads and stores on x64 AVX512?

On an x64 AVX512 machine with 64-byte (16-int) vectors, fully aligned loads and stores perform up to 50% faster than fully misaligned ones, with store alignment alone contributing about a 20% difference over load alignment alone. Smaller vectors (8 bytes) show only about a 20% impact, since fewer of them cross cacheline boundaries when misaligned.

_developers benchmarking vectorized code follow findings like these on daily.dev._

## Similar posts on daily.dev

- [Auto Vectorization and the Vector API](https://daily.dev/posts/auto-vectorization-and-the-vector-api-giyp5aagg) · Inside Java · 1 upvotes · 0 comments

---

Tags: [#performance](https://daily.dev/tags/performance), [#java](https://daily.dev/tags/java), [#jvm](https://daily.dev/tags/jvm)

[View this post on daily.dev](https://daily.dev/posts/performance-impact-of-alignment-i36nfpbhb)