Using the 64-bit Linux version of Sun’s 1.6.0_03-b05 JDK, it completes in 1ms for me (yes, I mean 0.001s). Using the 64-bit version of OpenJDK’s 1.6.0-b09 JDK, it takes 4ms. Both runs were on an otherwise mostly idle Intel Q6600, using one of its 2.4GHz cores. This is pretty consistent on repeated trials.

However, I agree with your assessment of the approximate amount of time it would have to take to compute that loop, so it must be choosing not to run the loop. It’s allowed to make that decision, as there are no side effects.

According to “javap -c”, the loop code is still present in the bytecode. And if I run with the -Xint flag, then those times jump up to 57.4s for both Sun 1.6.0_03-b05 and OpenJDK 1.6.0-b09. The interpreted runs are still performing the loop calculations.

If I change the code, so it has a side effect that the compiler can’t optimize, I can force it to keep the loop (though it may make other changes, like unrolling it partially). I created a long variable “dummy”, and then put “dummy *= 3;” inside the loop. That slows both native implementations down to 5.43s, which is in the ballpark you’re describing. It’s actually running the loop.

Interestingly, if I only have “++dummy;” inside the loop, the optimizer is able to infer the results of that calculation; it takes only 0.16sec to do that (again with approximately equal times from both JDKs).