Java integer ++i not changing the value

Question

I just made this simple "program":

public static void main(String[] args) {
        int i = 1;
        int k = 0;
        while (true) {
            if(++i==0) System.out.println("loop: " + ++k);
        }
    }

Upon running this program, I immediately get the output:

(...)
loop: 881452
loop: 881453
loop: 881454
loop: 881455
loop: 881456
loop: 881457
loop: 881458
(...)

as if i would be always 0.

And in fact, when I debug in Eclipse, upon suspending the program, i would be always zero. When stepping through the loop, i would increment, but upon resuming and suspending the debugger, i is 0 again.

When I change i to long, upon running the program I need to wait quite a while before seeing the first loop: 1. In the debugger, upon pausing the program, i does increment: it's not 0, so it works as it should.

What's the problem with ++i as an int?

Answer 1

If you keep incrementing an integer type, it will eventually overflow, becoming a large negative value. If you keep going, it will eventually become 0 again, and the cycle will repeat.

There are convenience methods to help avoid inadvertent overflows, like Math.addExact(), but these wouldn't normally be used in a loop.

---

I know that it is overflowing. I'm just puzzled that it's overflowing THAT fast. And I find it strange that each time I suspend the debugger, i is 0.

When you suspend a running thread, consider the chance of the thread being in a slow call to println() that traversing a huge stack of Java and native OS code, versus the probability of landing in the test of your while loop, which is just incrementing a local variable. You'd have to have a pretty quick trigger finger to see anything other than the print statement. Try stepping through instead.

When something happens 4 billion times in a row, it's a pretty good guess it will happen next time. Branch prediction will help here in any case, and it's possible that your optimizing runtime removes the increment operation and test entirely, since the intervening values of i are never read.

Answer 2

As JohannesD suggested in a comment, it's hardly possible to count from 0 to Integer.MAX_VALUE (and, after the overflow, from -Integer.MAX_VALUE to 0 again) so quickly.

In order to verify the assumption that the JIT does some magic optimization here, I created a slightly modified program, introducing some methods make it easier to identify parts of the code:

class IntOverflowTest
{
    public static void main(String[] args) {
        runLoop();
    }

    public static void runLoop()
    {
        int i = 1;
        int k = 0;
        while (true) {
            if(++i==0) doPrint(++k);
        }
    }

    public static void doPrint(int k)
    {
        System.out.println("loop: " + k);
    }

}

The bytecode emitted and shown with javap -c IntOverflowTest brings no surprises:

class IntOverflowTest {
  IntOverflowTest();
    Code:
       0: aload_0
       1: invokespecial #1                  
       4: return

  public static void main(java.lang.String[]);
    Code:
       0: invokestatic  #2                  
       3: return

  public static void runLoop();
    Code:
       0: iconst_1
       1: istore_0
       2: iconst_0
       3: istore_1
       4: iinc          0, 1
       7: iload_0
       8: ifne          4
      11: iinc          1, 1
      14: iload_1
      15: invokestatic  #3                  
      18: goto          4

  public static void doPrint(int);
    Code:
       0: getstatic     #4                  
       3: new           #5                  
       6: dup
       7: invokespecial #6                  
      10: ldc           #7                  
      12: invokevirtual #8                  
      15: iload_0
      16: invokevirtual #9                  
      19: invokevirtual #10                 
      22: invokevirtual #11                 
      25: return
}

It clearly does increment both local variables (runLoop, offsets 4 and 11).

However, when running the code with -XX:+UnlockDiagnosticVMOptions -XX:+LogCompilation -XX:+PrintAssembly in a Hotspot Disassembler, the machine code eventually ends up to be the following:

Decoding compiled method 0x00000000025c2c50:
Code:
[Entry Point]
[Verified Entry Point]
[Constants]
  # {method} {0x000000001bb40408} 'runLoop' '()V' in 'IntOverflowTest'
  #           [sp+0x20]  (sp of caller)
  0x00000000025c2da0: mov    %eax,-0x6000(%rsp)
  0x00000000025c2da7: push   %rbp
  0x00000000025c2da8: sub    $0x10,%rsp         ;*synchronization entry
                                                ; - IntOverflowTest::runLoop@-1 (line 10)

  0x00000000025c2dac: mov    $0x1,%ebp          ;*iinc
                                                ; - IntOverflowTest::runLoop@11 (line 13)

  0x00000000025c2db1: mov    %ebp,%edx
  0x00000000025c2db3: callq  0x00000000024f6360  ; OopMap{off=24}
                                                ;*invokestatic doPrint
                                                ; - IntOverflowTest::runLoop@15 (line 13)
                                                ;   {static_call}
  0x00000000025c2db8: inc    %ebp               ;*iinc
                                                ; - IntOverflowTest::runLoop@11 (line 13)

  0x00000000025c2dba: jmp    0x00000000025c2db1  ;*invokestatic doPrint
                                                ; - IntOverflowTest::runLoop@15 (line 13)

  0x00000000025c2dbc: mov    %rax,%rdx
  0x00000000025c2dbf: add    $0x10,%rsp
  0x00000000025c2dc3: pop    %rbp
  0x00000000025c2dc4: jmpq   0x00000000025b0d20  ;   {runtime_call}
  0x00000000025c2dc9: hlt

One can clearly see that it does not increment the outer variable i any more. It only calls the doPrint method, increments a single variable (k in the code), and then and immediately jumps back to the point before the doPrint call.

So the JIT indeed seems to detect that there is no real "condition" involved for printing the output, and that the code is equivalent to an infinite loop that only prints and increments a single variable.

_{This seems like a quite sophisticated optimization for me. I would expect that it's far from trivial to detect a case like this. But obviously, they managed to do so...}

Answer 3

Your loop is overflowing i. You have no break, so after a period of time, i wraps back to 0, and this prints the statement and increments k. This also explains why changing the int to a long causes the printing to slow down: it takes much longer for a long value to overflow.

Answer 4

First let's look at what that loop logically does.

i will repeatedly overflow. Every 2³² (about 4 billion) iterations of the loop the output will be printed and k will be incremented.

That is the logical view. However, compilers and runtimes are allowed to optimise and if you are getting more than a value every second or so it is pretty clear that such optimisation must be taking place. Even with modern branch prediction, out of order execution, etc. I find it unlikely that a CPU would get round a tight loop more than once per clock cycle (and even that I would consider unlikely). The fact that you never see anything other than zero in a debugger reinforces the idea that the code is being optimised away.

You mention it takes longer when "long" is used and that you do see other values. If a "long" counter was used in an unoptimised loop you would expect many decades between values. Again clearly optimisation is taking place, but it seems the optimiser is giving up before it has fully optimised away the pointless iterations.

Answer 5

It's not always 0, it becomes 0 after looping over (integer overflow), so it would first become Integer.MAX_VALUE, then Integer.MIN_VALUE, and then work its way up to 0 again. That's why it seems as if it is always 0, but in fact it takes all possible integer values before becoming 0... Over and over again.