Vector API support for vectors wider than 512 bits

[Ruben Ayrapetyan]

Hi Paul,
Thank you for the detailed response.

I appreciate this does not appear to be an urgent issue at this stage, and that there is a plan to address it eventually.

As the current toLong/fromLong helpers make the non-scalable code the easy path, I'm concerned that only adding an overload without deprecating/removing the original methods might leave a space for the portability issue: any library using the original toLong/fromLong would prevent applications from scaling to wider vector lengths.

I'd like to propose this similar option for consideration:
1. Introduce methods with the names emphasizing they deal with a part of mask only:
 - long toLongChunk(int chunkIndex)
 - static VectorMask<E> fromLongChunk(VectorSpecies<E> species, int chunkIndex, long bits)
 - int longChunkCount()
2. Deprecate (and eventually remove, while in incubator stage) fromLong / toLong - to steer towards the scalable version.

Does this direction seem reasonable?

There are a couple of other ideas on potential alternative approaches:
1. Using `long[]` array returned by `toLong` and accepted by `fromLong`. Presumably, there is an issue with having to allocate object even for 1-2 `long` chunks.
2. If value types are considered for Vector API, using a `{ long, long, long, long }` value to represent the bitmask returned by `toLong` / accepted by `fromLong` methods. This, however, would still keep a certain limit to the vector width.

Separately, it might be helpful to have a diagnostic/testing portability-check mode of running a Java program that uses Vector API - which would provide the maximum vector size wider than supported by the hardware. This does not have to be optimized for performance, as the goal would be to ensure/verify semantic correctness with wider vectors.

What do you think about this?

Kind regards,
Ruben

________________________________
From: Paul Sandoz <paul.sandoz at oracle.com>
Sent: 30 January 2026 23:20
To: Ruben Ayrapetyan <Ruben.Ayrapetyan at arm.com>
Cc: panama-dev at openjdk.org <panama-dev at openjdk.org>; Paul Sandoz <psandoz at openjdk.org>
Subject: Re: Vector API support for vectors wider than 512 bits

Hi Ruben,

They should be refined eventually, perhaps by adding an override accepting a part number following similar patterns in other places of the API. A reason why we have not prioritized this so far is:

1) AFAICT there is currently no commonly available hardware that goes beyond a cache line size in vector size. Thereby reducing the urgency. I would be interested in knowing if my assumption is incorrect!

2) There are related implementation issues when shuffling bytes, since the underlying shuffle implementation of bytes stores the indices in a byte[] array. This is more disruptive to address than the first one.

Paul.

On Jan 30, 2026, at 3:05 AM, Ruben Ayrapetyan <Ruben.Ayrapetyan at arm.com> wrote:

Hi all,

The question is related to Vector API compatibility with various vector lengths.

Some of the interfaces appear to be limiting support to 512-bit vectors, for example:
 - VectorMask.toLong throws an exception for vectors with more than 64 lanes;
 - VectorMask.fromLong replicates the sign bit into lane 64 and beyond.

As far as I understand from the documentation, the wider vectors are meant to be supported though not necessarily optimized for initially:
"Although the API has been designed to ensure ARM SVE instructions can be supported (vector sizes between 128 and 2048 bits)"

As the Java programs using the interfaces might not be compatible with an architecturally valid hardware platform, is there a possibility to refine the interfaces to ensure they scale to wider vectors?

Kind regards,
Ruben
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/panama-dev/attachments/20260206/970eee66/attachment-0001.htm>