Java / Java 25 Vector API Interview questions

The Vector API lives in the jdk.incubator.vector module and lets you write explicit SIMD (single instruction, multiple data) code in plain Java. You load a chunk of an array into a vector and apply one operation to every lane at once, instead of looping element by element.

At run time the C2 JIT compiler turns those calls into the widest vector instructions the CPU offers (SSE, AVX2, AVX-512, NEON, SVE). No native code or JNI is involved.

In Java 25 the API is still incubating, delivered by JEP 508, so it can change between releases.

SIMD means one CPU instruction works on several data elements held in a single wide register. A 256-bit register holds eight 32-bit ints, so one add instruction performs eight additions.

It matters whenever you run the same arithmetic over big arrays: numeric code, image filters, checksums, similarity search, text scanning. Scalar loops leave most of the register width unused.

It solves the unpredictability of auto-vectorization. C2 can vectorize simple loops by itself, but a small change such as an extra method call, a conditional, or an unusual reduction can silently switch it off. You get no error, just a slower loop.

With the Vector API you state the vector operations yourself. If the platform supports them, you get SIMD code; the result no longer depends on the optimizer recognizing your loop shape.

In Java 25 the Vector API is in its tenth incubation, delivered by JEP 508. Java 25 is an LTS release, but this particular API is not final: it stays in the jdk.incubator.vector module and can still change.

It is not a preview feature, so --enable-preview is not used. You add the module explicitly with --add-modules jdk.incubator.vector.

OpenJDK has said it will keep incubating until the Project Valhalla features it needs arrive as previews.

Because the API is an incubator module, it is not resolved by default. Pass --add-modules jdk.incubator.vector to both the compiler and the JVM.

javac --add-modules jdk.incubator.vector VecDemo.java
java  --add-modules jdk.incubator.vector VecDemo

For a named module, declare requires jdk.incubator.vector; in module-info.java. At startup the JVM prints a warning that an incubating module is in use. That is expected and harmless.

JEP 508 is the tenth incubation round of the Vector API, integrated into JDK 25. The Vector API began in JDK 16 with JEP 338 and has been re-incubated every release since. JEP 508 follows JEP 489 from JDK 24.

It has one API change: VectorShuffle can now be read from and written to a MemorySegment. It also carries two implementation-level changes.

The goal stays the same: let developers express vector computations that reliably compile to optimal vector instructions on supported CPUs.

A VectorSpecies describes a vector type: the element type plus the total vector size (its shape). Together they decide how many lanes a vector has. For example FloatVector.SPECIES_256 means float elements in 256 bits, which is 8 lanes.

Almost every factory method needs one, such as fromArray(species, array, offset) or zero(species). You can also query it:

• length() for lane count
• elementSize() in bits
• vectorBitSize() for total size
• loopBound(n) and indexInRange(i, n) for loop control

The API is small. These are the types you will meet in almost every example:

SPECIES_PREFERRED is a constant on each typed vector class, for example FloatVector.SPECIES_PREFERRED. It gives the species with the best shape for the current CPU, chosen by the JVM at startup. On x64 that is often 256 or 512 bits, depending on what the hardware and JVM settings allow; on AArch64 it depends on NEON or SVE.

Use it by default so one build adapts to the machine. Always read the lane count from SP.length() instead of hard-coding 8 or 16.

var SP = FloatVector.SPECIES_PREFERRED;
int lanes = SP.length();   // varies per machine

Use the static fromArray factory to load and intoArray to store. Both take an offset into the array, and the API bounds-checks them.

var SP = IntVector.SPECIES_PREFERRED;
int[] src = new int[1024];
int[] dst = new int[1024];

IntVector v = IntVector.fromArray(SP, src, 0);   // reads SP.length() ints
v.add(1).intoArray(dst, 0);                       // writes them back

A masked overload exists for both, which is how you deal with the end of an array. Unaligned offsets are fine; the API has no alignment requirement.

Run a vector loop up to loopBound, then finish the leftover elements with plain scalar code.

static final VectorSpecies<Float> SP = FloatVector.SPECIES_PREFERRED;

static void add(float[] a, float[] b, float[] c) {
    int i = 0;
    int upper = SP.loopBound(a.length);
    for (; i < upper; i += SP.length()) {
        FloatVector va = FloatVector.fromArray(SP, a, i);
        FloatVector vb = FloatVector.fromArray(SP, b, i);
        va.add(vb).intoArray(c, i);
    }
    for (; i < a.length; i++) {      // scalar tail
        c[i] = a[i] + b[i];
    }
}

Note the species is static final so the JIT can treat it as a constant.

A VectorMask holds one boolean per lane and decides which lanes an operation applies to. Masks come from comparisons, or from helpers such as species.indexInRange(i, n).

You can pass a mask to masked loads and stores, to blend, and to masked lane-wise ops. Useful queries are anyTrue(), allTrue(), trueCount() and firstTrue().

VectorMask<Float> positive = v.compare(VectorOperators.GT, 0f);
int count = positive.trueCount();

species.loopBound(n) returns the largest multiple of the lane count that is not greater than n. It is the safe upper limit for a loop that only processes full vectors.

With 8 lanes and 29 elements, loopBound(29) is 24. The vector loop covers indexes 0 to 23, and the remaining 5 elements are handled separately as the tail.

int upper = SP.loopBound(a.length);
for (int i = 0; i < upper; i += SP.length()) { /* full vectors only */ }

You have two options.

1. Scalar tail: after the vector loop, run a normal for loop over the remaining indexes. It is simple and works everywhere.
2. Masked tail: process the last partial chunk with a mask from species.indexInRange(i, n), so lanes past the end are switched off.

Masked loads and stores never touch the disabled lanes, so no out-of-bounds exception occurs for them. Always test arrays whose length is not a multiple of the lane count, including length 0 and 1.

VectorOperators is a class of constants that name operations, so you can pass them to generic methods such as lanewise, compare, reduceLanes and convert.

• Arithmetic and bitwise: ADD, SUB, MUL, AND, OR, XOR
• Comparisons: EQ, NE, LT, GT, LE, GE
• Conversions: I2F, F2I, B2S and similar

v.lanewise(VectorOperators.MUL, w);
v.compare(VectorOperators.GE, 0);
v.reduceLanes(VectorOperators.MAX);

Keep a running accumulator vector inside the loop and call reduceLanes only once at the end. Reducing on every iteration forces a slow cross-lane step each time.

static int sum(int[] a) {
    var SP = IntVector.SPECIES_PREFERRED;
    var acc = IntVector.zero(SP);
    int i = 0;
    for (int upper = SP.loopBound(a.length); i < upper; i += SP.length()) {
        acc = acc.add(IntVector.fromArray(SP, a, i));
    }
    int total = acc.reduceLanes(VectorOperators.ADD);
    for (; i < a.length; i++) total += a[i];
    return total;
}

VectorShape is an enum for the total bit size of a vector: S_64_BIT, S_128_BIT, S_256_BIT, S_512_BIT and S_Max_BIT. S_Max_BIT is the largest size the platform supports.

A species is shape plus element type, so you can build one with VectorSpecies.of(Float.class, VectorShape.S_256_BIT). VectorShape.preferredShape() returns the platform's preferred size.

Add the incubator module to compile time and to every JVM that runs the code, including tests and benchmarks.

Maven (compiler plus surefire):

<plugin>
  <artifactId>maven-compiler-plugin</artifactId>
  <configuration>
    <source>25</source>
    <target>25</target>
    <compilerArgs><arg>--add-modules</arg><arg>jdk.incubator.vector</arg></compilerArgs>
  </configuration>
</plugin>
<plugin>
  <artifactId>maven-surefire-plugin</artifactId>
  <configuration><argLine>--add-modules jdk.incubator.vector</argLine></configuration>
</plugin>

Gradle:

tasks.withType(JavaCompile) { options.compilerArgs += ['--add-modules', 'jdk.incubator.vector'] }
tasks.withType(Test)        { jvmArgs '--add-modules', 'jdk.incubator.vector' }
tasks.withType(JavaExec)    { jvmArgs '--add-modules', 'jdk.incubator.vector' }

If the compiler cannot see the module, try source and target instead of --release.

A FloatVector covers the usual arithmetic plus a set of math functions, all applied per lane.

Integer vectors add bitwise and shift operations such as AND, OR, XOR, LSHL, LSHR, ASHR.

It fits code that applies the same arithmetic to large, contiguous data:

• Numeric work: dot products, SAXPY, matrix multiply, statistics
• Similarity search: vector distance for embeddings; Apache Lucene uses it for this
• Media: image filters, audio buffers, pixel format conversion
• Bytes and text: scanning for a byte, UTF-8 validation, parsing
• Crypto and hashing: bulk bit operations

It is a poor fit for pointer-heavy structures and branchy business logic.

A VectorShuffle is a list of lane indexes that describes how to move lanes around. You build one, then apply it with vector.rearrange(shuffle): result lane i takes the value from source lane shuffle[i].

var SP = IntVector.SPECIES_128;                       // 4 lanes
var rev = VectorShuffle.fromValues(SP, 3, 2, 1, 0);
var v   = IntVector.fromArray(SP, new int[]{10, 20, 30, 40}, 0);
v.rearrange(rev);   // [40, 30, 20, 10]

Shuffles are a cross-lane operation, so use them sparingly in hot loops. Java 25 adds reading and writing a shuffle from a MemorySegment.

A lane-wise operation treats each lane independently: lane i of the result depends only on lane i of the inputs. add, mul and compare are examples. They map directly to a single fast instruction.

A cross-lane operation moves or combines data between lanes, for example reduceLanes, rearrange, slice, compress and expand. They are usually slower and CPU support varies.

Both end up as SIMD instructions, but the control is different. Auto-vectorization (C2's SuperWord) is a silent optimization on scalar loops. The Vector API is code where you spell out the vector steps.

Try auto-vectorization first. Reach for the API when you have measured that it is not enough.

The API depends on features that Project Valhalla has not delivered yet. Today a Vector is an ordinary object, and the JIT has to work hard to remove the boxing around it. Value classes would let vectors behave like primitives with no object identity.

OpenJDK has stated that it will keep re-incubating the API until the needed Valhalla features arrive as previews. Then the API will be adapted and promoted from incubation to preview.

That is why JEP 508 is the tenth round, and why code written against it should expect small changes later.

The classes in jdk.incubator.vector are written in Java, but the C2 compiler knows the hot methods as intrinsics. When C2 compiles your loop, it replaces calls like add or fromArray with matching machine instructions, and it tries to eliminate the vector objects so values stay in registers.

flowchart TD
  A["Your loop with FloatVector calls"] --> B{Hot enough for C2?}
  B -- No --> C["Interpreter or C1 runs the Java fallback code"]
  B -- Yes --> D["C2 intrinsifies vector operations"]
  D --> E["Escape analysis removes vector objects"]
  E --> F["CPU specific SIMD code: AVX2, AVX-512, NEON, SVE"]

If C2 cannot intrinsify an operation, or the vector objects escape, it falls back to slow object-based Java code.

The code still runs, but without hardware acceleration. The JVM falls back to a plain Java implementation that treats lanes as array elements and allocates objects. It is correct but can be much slower than a simple scalar loop.

This is the main risk of hard-coding a species such as SPECIES_512: on a CPU without AVX-512 you may pay for it. SPECIES_PREFERRED avoids that by choosing a size the machine handles well.

The JIT can only generate tight SIMD code if the species is a compile-time constant. A static final field lets C2 fold the lane count, element type and shape directly into the compiled loop.

If the species sits in a non-final field, a local that changes, or a method parameter that C2 cannot prove constant, the compiler cannot specialize. The code then uses slower generic paths and often allocates vector objects.

// good
static final VectorSpecies<Float> SP = FloatVector.SPECIES_PREFERRED;

// risky: not a constant to the JIT
VectorSpecies<Float> sp = FloatVector.SPECIES_PREFERRED;

The speed comes from C2, and C2 only compiles methods after they run enough times. Until then the interpreter and C1 execute the Java fallback implementation, which allocates vector objects for every operation.

So a one-shot call on a fresh JVM can look slower than a scalar loop. The fix is to let hot loops run long enough for C2 to compile them, and to benchmark with a proper harness such as JMH that includes warm-up iterations.

Very short-lived programs and cold paths may never benefit.

fma(b, c) computes this * b + c per lane with a single rounding, and on most CPUs in one instruction. A dot product keeps an accumulator vector and fuses the multiply and add.

static float dot(float[] a, float[] b) {
    var SP = FloatVector.SPECIES_PREFERRED;
    var acc = FloatVector.zero(SP);
    int i = 0;
    for (int upper = SP.loopBound(a.length); i < upper; i += SP.length()) {
        var va = FloatVector.fromArray(SP, a, i);
        var vb = FloatVector.fromArray(SP, b, i);
        acc = va.fma(vb, acc);
    }
    float sum = acc.reduceLanes(VectorOperators.ADD);
    for (; i < a.length; i++) sum += a[i] * b[i];
    return sum;
}

Results can differ slightly from a scalar loop because the summation order and the fused rounding are different.

Compute a mask with compare, then use blend or a masked operation to pick values per lane. Every lane follows the same instruction stream, so there is no branch to mispredict.

// clamp negatives to zero (ReLU style)
var v   = FloatVector.fromArray(SP, in, i);
var neg = v.compare(VectorOperators.LT, 0f);
v.blend(0f, neg).intoArray(out, i);

// same result using max
v.max(0f).intoArray(out, i);

Both sides of a condition are computed for all lanes, so this pays off when the branch is unpredictable and the work is cheap.

The Vector API can read and write a MemorySegment from the Foreign Function and Memory API, so you can vectorize data in native or mapped memory without copying it into a Java array. Pass the segment, a byte offset, and a byte order.

try (Arena arena = Arena.ofConfined()) {
    MemorySegment seg = arena.allocate(4096);
    var SP = FloatVector.SPECIES_PREFERRED;
    var v = FloatVector.fromMemorySegment(SP, seg, 0, ByteOrder.nativeOrder());
    v.mul(2f).intoMemorySegment(seg, 0, ByteOrder.nativeOrder());
}

Use ByteOrder.nativeOrder(); any other order forces a byte swap on every access. The offset counts bytes, not elements, and bounds are checked.

Java bytes are signed, and byte lanes wrap on overflow. A pixel value of 200 reads as -56 and adding 100 would wrap. The safe pattern is to widen the lanes first with a zero-extending conversion, compute in a wider type, then narrow again.

ByteVector px = ByteVector.fromArray(ByteVector.SPECIES_64, pixels, i);
// 8 byte lanes -> 8 int lanes, treated as unsigned
IntVector wide = (IntVector) px.convertShape(
        VectorOperators.ZERO_EXTEND_B2I, IntVector.SPECIES_256, 0);
IntVector bright = wide.add(40).min(255);

Narrowing back is done with a conversion such as I2B, and you should clamp first so the value fits.

Convert changes the values the way a Java cast does: an int lane 3 becomes float 3.0f. Reinterpret keeps the bits and just views them as another type: the int bits of 3 become a tiny denormal float.

When the lane count would change, such as int to double, convertShape takes a part number to select which piece of the result you want.

A gather loads lanes from scattered array positions using an index array. A scatter stores lanes to scattered positions. Both use the indexMap overloads of fromArray and intoArray.

int[] idx = {5, 2, 9, 0, 7, 1, 3, 8};   // 8 lanes
var v = FloatVector.fromArray(SP, data, 0, idx, 0);  // data[idx[j]]
v.mul(2f).intoArray(out, 0, idx, 0);                  // scatter back

Hardware support exists on some CPUs, such as AVX2 gathers and AVX-512 scatters, but it is slower than contiguous loads. Use it when the access pattern truly demands it, and prefer reorganizing data into contiguous arrays when you can.

Floating-point addition is not associative: (a + b) + c can differ from a + (b + c) in the last bits. A scalar loop adds elements in index order. A vector loop adds lane by lane into the accumulator and then combines the lanes, which is a different order.

The reduceLanes contract for floating-point add does not promise a particular order either. So a vector sum can legitimately differ slightly from the scalar sum.

Compare results with a tolerance in tests, not with ==. If you need bit-exact repeatable sums, use a fixed algorithm such as Kahan summation or integer arithmetic, and verify the order.

Integer lanes wrap around silently, exactly like Java's scalar int, short and byte arithmetic. IntVector.add on Integer.MAX_VALUE and 1 gives Integer.MIN_VALUE in that lane. There is no exception.

Narrow types overflow sooner. Adding two bytes of 100 gives -56. If values can grow, use a wider type, as in pixel and sum code, or clamp with min and max before the add.

Check boundary values in your tests: maximum, minimum, and zero for each lane type.

Both handle leftover elements. The difference is the trade-off.

for (int i = 0; i < n; i += SP.length()) {
    var m = SP.indexInRange(i, n);
    var va = FloatVector.fromArray(SP, a, i, m);
    var vb = FloatVector.fromArray(SP, b, i, m);
    va.add(vb).intoArray(c, i, m);
}

Choose the masked form for short arrays or when one code path matters. Choose the scalar tail when you want the simplest main loop on any hardware. Benchmark both.

Use SPECIES_PREFERRED by default; it adapts to the CPU. Pick a fixed species only when the algorithm needs a known lane count.

• Fixed layouts: processing 8 ints at a time because the data format has blocks of 8.
• Reproducibility: keeping the summation order identical across machines for floats.
• Measured wins: on some Intel CPUs 256-bit code runs faster than 512-bit because of clock throttling.

The risk: a fixed species the CPU lacks falls back to slow code. If you hard-code one, verify the machine supports it, or keep a preferred-species path too.

Skip it when it will not pay off or when the cost is not worth it.

• Scalar code is already fast: if C2 auto-vectorizes the loop, the API adds complexity for nothing.
• Memory-bound work: if the loop waits on RAM, wider arithmetic does not help.
• Tiny arrays or cold code: setup and warm-up cost exceed the gain.
• Irregular access: pointer chasing, heavy branching, small strings.
• Stability needs: it is an incubating API that can change between releases.

Measure first, and keep a scalar reference version for testing.

Use JMH. A hand-rolled System.nanoTime() test usually measures interpreter and C1 time, not the C2 code you care about.

1. Add the module to the benchmark JVM: @Fork(jvmArgsAppend = {"--add-modules", "jdk.incubator.vector"}).
2. Always benchmark against a scalar baseline on the same data.
3. Use realistic sizes, including ones that exceed the CPU cache.
4. Return or consume results so the JIT cannot remove the work.
5. Verify the vector result matches the scalar one before trusting timings.
6. Repeat on the hardware you deploy on, since results differ across CPUs.

Work through the likely causes in order. Most slow cases come from failing to get intrinsified, compiled code.

flowchart TD
  A["Vector code slower than scalar"] --> B{Warmed up and compiled by C2?}
  B -- No --> C["Use JMH with warm-up"]
  B -- Yes --> D{Species static final and supported?}
  D -- No --> E["Fix species, prefer SPECIES_PREFERRED"]
  D -- Yes --> F{Vector objects allocated in profile?}
  F -- Yes --> G["Stop vectors escaping: no fields, collections, or lambdas"]
  F -- No --> H{Memory bound?}
  H -- Yes --> I["Reduce memory traffic, block for cache"]
  H -- No --> J["Check cross-lane ops and gathers in the hot loop"]

Useful tools: a JFR or allocation profiler (look for classes such as Float256Vector being allocated), -XX:+PrintCompilation, JMH profilers like perfasm, and JITWatch. Seeing vector objects allocated in the hot loop is the classic sign the fallback is running.

Valhalla aims to bring value classes (objects without identity) and better generics to Java. Those are exactly the features that would make vectors cheap: a value-class vector could be stored flat, passed in registers, and not need escape analysis to avoid allocation.

Today a vector is a normal heap object that C2 tries to remove. Also, Vector<E> is generic over primitive element types like Float, which today means boxing-like indirection in the type system.

That coupling is why the Vector API will stay in incubation until the necessary Valhalla features are available as previews. After that it can be adapted and promoted.

Vector and its subclasses are value-based. They are immutable, and the API makes no promise about identity: two vectors with the same lanes may or may not be the same object, and the JIT may create or remove instances freely.

• == compares references and can give a surprising answer. Use eq(other) for a per-lane mask or compare the arrays.
• synchronized on a value-based instance is discouraged and may be flagged, since the identity may vanish.

Because vectors are immutable, they are naturally thread-safe and never need locking. Each operation returns a new vector.

JNI or the FFM API lets you call native C code that uses intrinsics or a library like BLAS. The Vector API keeps the logic in Java and relies on the JIT.

For standard linear algebra, a tuned native library can still beat Java code. For custom loops in Java projects, the Vector API avoids the packaging and call cost.

You write against abstract vector types, and the JVM maps them to what the hardware has. On x64 that may be SSE, AVX2 or AVX-512. On AArch64 it may be NEON or SVE. Your source does not change.

Portability here means correctness everywhere, not identical speed everywhere. A species the CPU lacks still works, but through a slow fallback. Some operations map to a single instruction on one CPU and a longer sequence on another.

To keep code portable: use SPECIES_PREFERRED, read lane counts from the species, avoid assuming lane order tricks, and benchmark on each target CPU you care about.

Both use a mask. compress takes the lanes the mask selects and packs them into the lowest lanes, filling the rest with zeros. expand does the reverse: it spreads the low lanes into the positions the mask selects.

// filter: keep positive ints, packed
var v = IntVector.fromArray(SP, in, i);
var m = v.compare(VectorOperators.GT, 0);
int n = m.trueCount();
v.compress(m).intoArray(out, pos, SP.indexInRange(0, n));
pos += n;

That gives a branch-free filter. Both are cross-lane operations, and speed depends on CPU support such as AVX-512.

a.slice(k, b) treats a followed by b as one long run of lanes and returns a window of one vector length that starts at lane k. With 4 lanes, a = [0,1,2,3] and b = [4,5,6,7], a.slice(1, b) gives [1,2,3,4].

That is exactly what you need for sliding windows, such as convolution or neighbor differences, without reloading overlapping data. unslice is the inverse operation: it places this vector's lanes into a result at a given offset.

var cur  = IntVector.fromArray(SP, a, i);
var next = IntVector.fromArray(SP, a, i + SP.length());
var shifted = cur.slice(1, next);      // a[i+1 ... i+L]
cur.sub(shifted).intoArray(diff, i);

They exploit different kinds of parallelism and can be combined.

For a very large array you can split the work into chunks across threads and use the Vector API inside each chunk. Remember that memory bandwidth is shared, so adding threads may stop helping.

Compare a whole vector against the target in one step, then use the mask: anyTrue() tells you if there was a match, and firstTrue() gives its lane. This lets you scan many bytes per iteration and exit early.

static int indexOf(byte[] a, byte target) {
    var SP = ByteVector.SPECIES_PREFERRED;
    int i = 0;
    for (int upper = SP.loopBound(a.length); i < upper; i += SP.length()) {
        var m = ByteVector.fromArray(SP, a, i).compare(VectorOperators.EQ, target);
        if (m.anyTrue()) return i + m.firstTrue();
    }
    for (; i < a.length; i++) if (a[i] == target) return i;
    return -1;
}

Byte vectors have many lanes (32 or 64 on wide CPUs), so this scales well for text and binary scanning.

If a loop is limited by RAM bandwidth, wider arithmetic does little. The aim is to cut memory traffic and keep data in cache.

1. Fuse passes: do several steps in one pass over the data instead of writing intermediate arrays.
2. Block for cache: process tiles that fit in L1 or L2, as in matrix multiply.
3. Use smaller types: floats instead of doubles, or bytes where precision allows, so each load carries more lanes.
4. Prefer contiguous access: avoid gathers and strided reads.
5. Use several accumulators: unroll with two or four independent accumulator vectors to hide instruction latency in reductions.

Verify with a benchmark whether you are limited by bandwidth or by compute; the remedy differs.