RFR: 8349452: Fix performance regression for Arrays.fill() with AVX512 [v11]
Srinivas Vamsi Parasa
sparasa at openjdk.org
Tue Jan 6 23:44:27 UTC 2026
On Tue, 6 Jan 2026 08:38:36 GMT, Emanuel Peter <epeter at openjdk.org> wrote:
> Can you explain a bit more, and maybe add an additional column that gives us a speedup number?
>
Hi Emanuel (@eme64),
Currently, with +OptimizeFill flag, the fill intrinsic uses the **masked vector store** operation. From a performance point of view, the masked store operation, as shown in the left most column, has a **zig-zag pattern for latency** (i.e. time taken for the fill) as the array size increases. For example, for sizes in 1 to 16, it takes 0.43 secs for the masked store, whereas, it takes 0.21 seconds for the same masked store for sizes 17 to 32.
Without the fill intrinsic (-OptimizeFill), in the middle column, the fill latency increases linearly with respect to the size of the array. For small sizes <=16, the JITed code (-OptimizeFill) is faster than the intrinsic (+OptimizeFill) using masked store, thereby causing the performance regression reported.
This PR (right most column), replaces the zig-zig behavior of the masked store (left most column), with a more predictable fill using unmasked stores whose latency increases as log(N), where N is the size of the array. This is better than without the intrinsic (-OptimizeFill) but in some cases is slower than the masked store due to its **zig-zag behavior**.
As suggested, I will also provide the following data:
- Performance data for byte, short and int (the types affected by this PR) with plots for sizes upto 300.
- Performance data taking alignment (arbitrary offset) into consideration (`Arrays.fill(type[] a, int fromIndex, int toIndex, type val`)
- Performance data using fill_var_*_arrays_fill bencharks from your recent PR
- Performance data prior to [JDK-8275047](https://bugs.openjdk.org/browse/JDK-8275047)
Thanks,
Vamsi
-------------
PR Comment: https://git.openjdk.org/jdk/pull/28442#issuecomment-3716740610
More information about the hotspot-dev
mailing list