Variability of the performance of Vector<E>

[Bhateja, Jatin]

[AMD Official Use Only - AMD Internal Distribution Only]

Unless the starting address of first element of arrays (&arr[0]) is multiple of maximum possible vector size supported by the target we may leave the room for mis-alignment penalty as 64-byte alignment guarantees
32 and 16-byte alignment but not vice versa. Both vector-API by means of various species and auto-vectorization based on unrolling factor can dynamically pick the vector size, but hyper-alignment should be sacrosanct and/or dependent on a JVM flag.

Best Regards,
Jatin

-----Original Message-----
From: panama-dev <panama-dev-retn at openjdk.org> On Behalf Of Paul Sandoz
Sent: 08 January 2026 06:35
To: John Rose <john.r.rose at oracle.com>
Cc: Daniel Lemire <daniel at lemire.me>; Peter Kessler OS <peter.kessler at os.amperecomputing.com>; hotspot-gc-dev at openjdk.org; panama-dev <panama-dev at openjdk.org>
Subject: Re: Variability of the performance of Vector<E>

Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding.


> On Jan 7, 2026, at 4:42 PM, John Rose <john.r.rose at oracle.com> wrote:
>
> What I think (or hope) is that a large array hyper-alignment feature
> could silently patch up a number of such artifacts.
>

That's very appealing and transparent to the user. I would be interested in hearing what GC folks think. (I am skeptical of exposing too much of a user model, for similar reasons why we have not done so already for say contended fields, as users will get it wrong or over exploit it to their detriment).

If it works well it might also simplify any pre-loop of C2’s auto-vectorizer that pre-aligns (although when there are 2 or more inputs the stars need to align :-) ).

Paul.