P4
Arrays are aligned to 64-bit boundaries (on 64-bit machines), unless ObjectAlignmentInBytes is set to a larger value like 16 (128-bit size) or 64 (cache line size).
This causes vectorized loops to have an unstable performance, depending on whether vector accesses cross cache lines or not. This observation applies to auto-vectorized JIT code, and also to manually vectorized code.
For an example of the latter, see https://mail.openjdk.org/pipermail/hotspot-gc-dev/2026-January/056951.html
Let’s fix that, at least in some GCs and some JVM configurations, by hyper-aligning all Java arrays that are larger than some threshold size.
Specifically, define a new JVM option -XX:HyperAlignedArraySizeInBytes=N, and ask at least some GCs to respect it as follows: When the threshold N is non-zero, and when allocating an array whose size in bytes meets or exceeds the threshold, the array location is adjusted so that the memory address of its first element is a multiple of the cache line size, or some other parameter that is appropriate to vectorization performance (half cache line size, etc.).
The adjustment can be GC specific: Either a padding object is prepended to raise the array address appropriately, or else the whole array is allocated in a different memory segment (maybe like the large array segments of G1).
Whenever the array is reallocated (by a copying GC), the alignment requirement is applied again. This might mean (for some GCs) that the array header pattern is adjusted somehow to record the decision to give the array special processing. (Or a simple range check on the length is done, again.)
The VM ergonomically sets HyperAlignedArraySizeInBytes to a value that is large enough not to cause needless overheads (with smaller arrays), or to zero if the GC cannot support hyper alignment.
When the VM starts up with a user-requested HyperAlignedArraySizeInBytes value that cannot be met by the GC, a warning is printed and the value is reset to zero.
Probably there is a second option -XX:HyperAlignmentInBytes=N, with a corresonding ergonomic policy.
Both flags can be diagnostic, since they are useful mainly for tuning the JVM itself.
There are several possible features in this design space:
0. Hyper-alignment of arrays as a property of array length. This is what is described above.
1. Hyper-alignment as a property of each individual array rather than of array length; a new array factory would create hyper-aligned arrays even with just one element. (This would mandate some kind of header-bit trick.)
2. Hyper-alignment as a property of array element layout rather than of array length; an array of 128-bit Valhalla values might be hyper-aligned even with just one element.
3. Hyper-alignment as a property of individual class instances. The header (or first field) of the object would be hyper-aligned.
4. Hyper-alignment as a property of field types, which the containing object or array would honor. This could support 128-bit value types, or other hardware vector types.
5. Varying levels of hyper-alignment, of vector sizes, rather than just the cache line size.
There is a moderately complex design space here. It may be profitable to pick a few points, even beyond step 0.
Some related RFEs:
JDK-8167334 optional hyper-alignment for value types like Long4/Bits256
JDK-8234886 generic data holder objects in Java heap, with hyper-alignment option
JDK-8235370 Storage class wrapper types
This causes vectorized loops to have an unstable performance, depending on whether vector accesses cross cache lines or not. This observation applies to auto-vectorized JIT code, and also to manually vectorized code.
For an example of the latter, see https://mail.openjdk.org/pipermail/hotspot-gc-dev/2026-January/056951.html
Let’s fix that, at least in some GCs and some JVM configurations, by hyper-aligning all Java arrays that are larger than some threshold size.
Specifically, define a new JVM option -XX:HyperAlignedArraySizeInBytes=N, and ask at least some GCs to respect it as follows: When the threshold N is non-zero, and when allocating an array whose size in bytes meets or exceeds the threshold, the array location is adjusted so that the memory address of its first element is a multiple of the cache line size, or some other parameter that is appropriate to vectorization performance (half cache line size, etc.).
The adjustment can be GC specific: Either a padding object is prepended to raise the array address appropriately, or else the whole array is allocated in a different memory segment (maybe like the large array segments of G1).
Whenever the array is reallocated (by a copying GC), the alignment requirement is applied again. This might mean (for some GCs) that the array header pattern is adjusted somehow to record the decision to give the array special processing. (Or a simple range check on the length is done, again.)
The VM ergonomically sets HyperAlignedArraySizeInBytes to a value that is large enough not to cause needless overheads (with smaller arrays), or to zero if the GC cannot support hyper alignment.
When the VM starts up with a user-requested HyperAlignedArraySizeInBytes value that cannot be met by the GC, a warning is printed and the value is reset to zero.
Probably there is a second option -XX:HyperAlignmentInBytes=N, with a corresonding ergonomic policy.
Both flags can be diagnostic, since they are useful mainly for tuning the JVM itself.
There are several possible features in this design space:
0. Hyper-alignment of arrays as a property of array length. This is what is described above.
1. Hyper-alignment as a property of each individual array rather than of array length; a new array factory would create hyper-aligned arrays even with just one element. (This would mandate some kind of header-bit trick.)
2. Hyper-alignment as a property of array element layout rather than of array length; an array of 128-bit Valhalla values might be hyper-aligned even with just one element.
3. Hyper-alignment as a property of individual class instances. The header (or first field) of the object would be hyper-aligned.
4. Hyper-alignment as a property of field types, which the containing object or array would honor. This could support 128-bit value types, or other hardware vector types.
5. Varying levels of hyper-alignment, of vector sizes, rather than just the cache line size.
There is a moderately complex design space here. It may be profitable to pick a few points, even beyond step 0.
Some related RFEs:
JDK-8234886 generic data holder objects in Java heap, with hyper-alignment option