does JVM skip a temporary generic conversion

I'm looking for a way to use primitive collections with generic interfaces.

In the case of IntArray class and scenario function, will JVM create temporary Integer objects, or directly pass an int?

Elements are stored in a primitive int[] and assigned only directly to primitive int so leaving this unoptimized, implies unnecessary object creation, just to destroy it in a fraction of second.

public class Test {
private interface Array<E> {
E get(int index);
void set(int index, E element);
}
private static class GenericArray<E> implements Array<E> {
private final E[] elements;
@SuppressWarnings("unchecked")
public GenericArray(int capacity) {
this.elements = (E[]) new Object[capacity];
}
@Override
public E get(int index) {
return elements[index];
}
@Override
public void set(int index, E element) {
elements[index] = element;
}
}
private static class IntArray<E> implements Array<Integer> {
private final int[] elements; // primitive int array
public IntArray(int capacity) {
this.elements = new int[capacity];
}
@Override
public Integer get(int index) {
return elements[index];
}
@Override
public void set(int index, Integer element) {
elements[index] = element;
}
}
private static void scenario(Array<Integer> array) {
int element = 256;
array.set(16, element);  // primitive int given
element = array.get(16); // converted directly to primitive int
System.out.println(element);
}
public static void main(String[] args) {
Array<Integer> genericArray   = new GenericArray<>(64);
Array<Integer> primitiveArray = new IntArray<>(64);
scenario(genericArray);
scenario(primitiveArray);
}
}

Java does not have generics over primitive types (yet).

Your IntArray deals with Integer objects, at least at the bytecode level. If we decompile the class, we'll clearly see calls to the boxing Integer.valueOf and unboxing Integer.intValue methods:

javap -c -private Test$IntArray

  public java.lang.Integer get(int);
Code:
0: aload_0
1: getfield      #2      // Field elements:[I
4: iload_1
5: iaload
6: invokestatic  #3      // Method java/lang/Integer.valueOf:(I)Ljava/lang/Integer;
9: areturn
public void set(int, java.lang.Integer);
Code:
0: aload_0
1: getfield      #2      // Field elements:[I
4: iload_1
5: aload_2
6: invokevirtual #4      // Method java/lang/Integer.intValue:()I
9: iastore
10: return

However, JIT compiler has an optimization to eliminate redundant boxing-unboxing pairs: -XX:+EliminateAutoBox. The optimization is ON by default, but unfortunately does not always work. Let's see if it works in your case with the help of the JMH benchmark.

package bench;
import org.openjdk.jmh.annotations.*;
@State(Scope.Benchmark)
public class GenericArrays {
Array<Integer> genericArray = new GenericArray<>(64);
Array<Integer> primitiveArray = new IntArray(64);
int n;
@Setup
public void setup() {
for (int i = 0; i < 64; i++) {
genericArray.set(i, i + 256);
primitiveArray.set(i, i + 256);
}
}
@Benchmark
public int getGeneric() {
return genericArray.get(n++ & 63);
}
@Benchmark
public int getPrimitive() {
return primitiveArray.get(n++ & 63);
}
@Benchmark
@Fork(jvmArgsAppend = "-XX:-EliminateAutoBox")
public int getPrimitiveNoOpt() {
return primitiveArray.get(n++ & 63);
}
@Benchmark
public void setGeneric() {
genericArray.set(n++ & 63, n);
}
@Benchmark
public void setPrimitive() {
primitiveArray.set(n++ & 63, n);
}
@Benchmark
@Fork(jvmArgsAppend = "-XX:-EliminateAutoBox")
public void setPrimitiveNoOpt() {
primitiveArray.set(n++ & 63, n);
}
private interface Array<E> {
E get(int index);
void set(int index, E element);
}
static class GenericArray<E> implements Array<E> {
private final E[] elements;
@SuppressWarnings("unchecked")
public GenericArray(int capacity) {
this.elements = (E[]) new Object[capacity];
}
@Override
public E get(int index) {
return elements[index];
}
@Override
public void set(int index, E element) {
elements[index] = element;
}
}
static class IntArray implements Array<Integer> {
private final int[] elements;
public IntArray(int capacity) {
this.elements = new int[capacity];
}
@Override
public Integer get(int index) {
return elements[index];
}
@Override
public void set(int index, Integer element) {
elements[index] = element;
}
}
}

When run the benchmark on JDK 14.0.2, I get the following scores (lower is better).

Benchmark                        Mode  Cnt     Score     Error   Units
GenericArrays.getGeneric         avgt   20     3,769 ±   0,039   ns/op
GenericArrays.getPrimitive       avgt   20     3,445 ±   0,037   ns/op
GenericArrays.getPrimitiveNoOpt  avgt   20     5,147 ±   0,073   ns/op
GenericArrays.setGeneric         avgt   20    10,491 ±   0,055   ns/op
GenericArrays.setPrimitive       avgt   20     3,896 ±   0,023   ns/op
GenericArrays.setPrimitiveNoOpt  avgt   20     4,078 ±   0,077   ns/op

This leads us to two observations:

• Primitive array seems to perform better;
• EliminateAutoBox optimization apparently works, since when the optimization is off, the timings are higher.

Now let's verify if the optimization helps to avoid unnecessary allocations.
GC profiler built into JMH (-prof gc) will do the job.

Benchmark                                            Mode  Cnt     Score     Error   Units
GenericArrays.getGeneric:·gc.alloc.rate.norm         avgt   20    ≈ 10⁻⁵              B/op
GenericArrays.getPrimitive:·gc.alloc.rate.norm       avgt   20    ≈ 10⁻⁵              B/op
GenericArrays.getPrimitiveNoOpt:·gc.alloc.rate.norm  avgt   20    16,000 ±   0,001    B/op
GenericArrays.setGeneric:·gc.alloc.rate.norm         avgt   20    16,000 ±   0,001    B/op
GenericArrays.setPrimitive:·gc.alloc.rate.norm       avgt   20    16,000 ±   0,001    B/op
GenericArrays.setPrimitiveNoOpt:·gc.alloc.rate.norm  avgt   20    16,000 ±   0,001    B/op

Here we see that the allocation rate of getPrimitive benchmark is zero. This means, the JVM was able to eliminate allocation of a temporary Integer object. When the optimization is off, the allocation rate is expectedly 16 bytes per operation - exactly the size of one Integer object.

For some reason, JVM was not able to eliminate boxing in setPrimitive. As I've told earlier, the optimization is fragile and does not work in all cases.

However, setPrimitive is still a way faster than setGeneric. The benefit comes from the fact that storing a primitive is more efficient than storing a reference, because storing a reference typically requires a GC barrier.

> „…does JVM skip a temporary generic conversion…“

No. It doesn't. It does a Boxing Conversion…

> …
>
> 5.1.7 Boxing Conversion
>
> Boxing conversion treats expressions of a primitive type as expressions of a corresponding reference type. Specifically, the following nine conversions are called the boxing conversions:
>
> …
> * From type int to type Integer
>
> …

…And an Unboxing Conversion…

> …
>
> 5.1.8. Unboxing Conversion
>
> Unboxing conversion treats expressions of a reference type as expressions of a corresponding primitive type. Specifically, the following eight conversions are called the unboxing conversions:
>
> …
>
> * From type Integer to type int
>
> …

See the Java Tutorial's Autoboxing and Unboxing trail.

> „…will JVM create temporary Integer objects, or directly pass an int?…“

It does both. First the former followed finally by the latter.

> „…unnecessary object creation, just to destroy it in a fraction of second…“

The architects at Oracle that design the Java language probably agree with you…

>> „…The problem with boxing is that it is [ad-hoc] and expensive; extensive work has gone on under the hood to address both of these concerns…“ — Brian Goetz, State of Valhalla, March 2020

And they have a solution in mind for your request…

> „…for a way to use primitive collections with generic interfaces…“

…If you're patient…

>> „…We are trying to preserve room for specialized generics as a future feature… We wish to reserve a natural notation in the future for specialized types, such as List<int>…“ — Migration: specialized generics, Brian Goetz, State of Valhalla

Specialized generics aren't a thing yet. But you can take other early-access features of Valhalla out for a spin today.