The following code hangs forever when run by the server version of JVM:

public class OptimizerBug {<br>    private static final int ITERATIONS = 1000;<br>    private static int doNotOptimizeOut = 0;<br><br>    public static long bitCountShort() {<br>        long t0 = System.currentTimeMillis();<br>        int sum = 0;<br>        for (int it = 0; it < ITERATIONS; ++it) {<br>            short value = 0;<br>            do {<br>                sum += Integer.bitCount(value);<br>            } while (++value != 0);<br>        }<br>        doNotOptimizeOut += sum;<br>        return System.currentTimeMillis() - t0;<br>    }<br><br>    public static void main(String[] args) {<br>        for (int i = 0; i < 4; ++i) {<br>            System.out.println((i + 1) + ": " + bitCountShort());<br>        }<br>        System.out.println("doNotOptimizeOut value: " + doNotOptimizeOut);<br>    }<br>}<br>

The example of results it produced (on the same machine, Linux Gentoo 64-bit, java 1.6.0_24):

• [64-bit] java OptimizerBug:

1: 380
2: 373
<hangs>

• [32-bit] java -server OptimizerBug:

1: 386
2: 365
<hangs>

• [32-bit] java -client OptimizerBug

1: 525
2: 520
3: 518
4: 526
doNotOptimizeOut value: -100663296

When on Linux, in the case of hang the process takes both (all?) the CPU cores and can be killed only by signal 9.

On 64-bit Windows (java 1.6.0_23), the same happens, but the process takes only one CPU core.

The Sun Bug ID is 7020614:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7020614.

UPD: The bug became visible by the link above. One may vote for it there.

The following code produces strange results while compiling it under GCC with different optimization levels:

• gcc source.cpp -> 0.440 s
• gcc -O2 source.cpp -> 2.750 s (-O, -O1, -O2 the same)
• gcc -Os source.cpp -> 0.223 s

For N=500, it is as follows:

• gcc source.cpp -> 3.931 s
• gcc -Os source.cpp -> 2.704 s
• gcc -O2 source.cpp -> 42.142 s
  

The setup is GCC 4.4.4 on 64-bit Gentoo Linux.

Somehow optimizations by speed significantly slow the code, while optimizations by size speed it up :-)

Could anybody compile and test the code on your machines? Or, possibly, explain why it is like this?