Remainder operator on int causes java.util.Objects.requireNonNull?

Question

I'm trying to get as much performance as possible from some internal method.

The Java code is:

List<DirectoryTaxonomyWriter> writers = Lists.newArrayList();
private final int taxos = 4;

[...]

@Override
public int getParent(final int globalOrdinal) throws IOException {
    final int bin = globalOrdinal % this.taxos;
    final int ordinalInBin = globalOrdinal / this.taxos;
    return this.writers.get(bin).getParent(ordinalInBin) * this.taxos + bin; //global parent
}

In my profiler I saw there is 1% CPU spend in java.util.Objects.requireNonNull, but I don't even call that. When inspecting the bytecode, I saw this:

 public getParent(I)I throws java/io/IOException 
   L0
    LINENUMBER 70 L0
    ILOAD 1
    ALOAD 0
    INVOKESTATIC java/util/Objects.requireNonNull (Ljava/lang/Object;)Ljava/lang/Object;
    POP
    BIPUSH 8
    IREM
    ISTORE 2

So the compiler generates this (useless?) check. I work on primitives, which cannot be null anyways, so why does the compiler generate this line? Is it a bug? Or 'normal' behaviour?

(I might work around with a bitmask, but I'm just curious)

[UPDATE]

1. The operator seems to be having nothing to do with it (see answer below)

2. Using the eclipse compiler (version 4.10) I get this more reasonable result:

    public getParent(I)I throws java/io/IOException 
       L0
        LINENUMBER 77 L0
        ILOAD 1
        ICONST_4
        IREM
        ISTORE 2
       L1
        LINENUMBER 78 L

So that is more logical.

Answer 1

Why not?

Assuming

class C {
    private final int taxos = 4;

    public int test() {
        final int a = 7;
        final int b = this.taxos;
        return a % b;
    }
}

a call like c.test() where c is declared to as C must throw when c is null. Your method is equivalent to

    public int test() {
        return 3; // `7 % 4`
    }

as you work with constants only. With test being non-static, the check must be done. Normally, it would get done implicitly when a field gets accessed or a non-static method gets called, but you don't do it. So an explicit check is needed. One possibility is to call Objects.requireNonNull.

The bytecode

Forget not that the bytecode is basically irrelevant for the performance. The task of javac is to produce some bytecode whose execution corresponds with your source code. It's not meant to do any optimizations, as optimized code is usually longer and harder to analyze, while the bytecode is actually the source code for the optimizing JIT compiler. So javac is expected to keep it simple....

The performance

In my profiler I saw there is 1% CPU spend in java.util.Objects.requireNonNull

I'd blame the profiler first. Profiling Java is pretty hard and you can never expect perfect results.

You probably should try making the method static. You surely should read this article about null checks.

Answer 2

Firstly, here's a minimal reproducible example of this behavior:

/**
 * OS:              Windows 10 64x
 * javac version:   13.0.1
 */
public class Test {
    private final int bar = 5;

    /**
     * public int foo();
     *   Code:
     *     0: iconst_5
     *     1: ireturn
     */
    public int foo() {
        return bar;
    }

    /**
     * public int foo2();
     *   Code:
     *     0: aload_0
     *     1: invokestatic  #13     // Method java/util/Objects.requireNonNull:(Ljava/lang/Object;)Ljava/lang/Object;
     *     4: pop
     *     5: iconst_5
     *     6: ireturn
     */
    public int foo2() {
        return this.bar;
    }
}

The behavior is because of how the Java compiler optimizes compile-time constants.

Note that in the byte code of foo() no object reference is accessed to get the value of bar. That's because it is a compile-time constant and thus the JVM can simply execute the iconst_5 operation to return this value.

When changing bar into a non-compile time constant (either by removing the final keyword or not initializing within declaration but inside the constructor) you would get:

/**
 * OS:              Windows 10 64x
 * javac version:   13.0.1
 */
public class Test2 {
    private int bar = 5;

    /**
     * public int foo();
     *   Code:
     *     0: aload_0
     *     1: getfield      #7
     *     4: ireturn
     */
    public int foo() {
        return bar;
    }

    /**
     * public int foo2();
     *   Code:
     *     0: aload_0
     *     1: getfield      #7
     *     4: ireturn
     */
    public int foo2() {
        return this.bar;
    }
}

where aload_0 pushes the reference of this onto the operand stack to then get the bar field of this object.

Here the compiler is clever enough to notice that aload_0 (the this reference in case of member functions) can logically not be null.

Now is your case actually a missing compiler optimization?

See @maaartinus answer.