It seems that the hotspot-compiler has problems with loop variables of type long on the Itanium plattform for jdk 1.4.2.

Consider the following short test program:

---------------------------------------------------------------------------
public class TestLongLoop
{
    public static Integer getInteger()
    {
        long index;
        for(index = 10 ; index < Long.MAX_VALUE ; index++)
        {
          if (index > 2000) return new Integer((int)index); // (1)
        }

        System.out.println("INDEX is " + index);
        return null;
    }

    public static void main(String[] args)
        throws Exception
    {
        for(int i = 0 ; i < 1000 ; ++i) // (2)
        {
            Integer x = getInteger();
            if(x==null)
            {
                System.out.println("GOT null after " + i + " iterations!");
                System.exit(20);
            }
        }
    }
}
---------------------------------------------------------------------------

On Linux/x86 and on Solaris, the program just terminates without any output.
On Linux/Itanium (and on Windows/Itanium) with jdk 1.4.2 (see below for the exact version) the program always terminates with the following output:

$ uname -a
Linux jtg-it4 2.4.21-4.EL #1 SMP Fri Oct 3 17:29:39 EDT 2003 ia64 ia64 ia64 GNU/Linux
$ java -showversion -Xmixed TestLongLoop
java version "1.4.2_08"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_08-b03)
Java HotSpot(TM) 64-Bit Server VM (build 1.4.2_08-b03, mixed mode)

INDEX is 11
GOT null after 182 iterations!

This means that the for-loop in the method getInteger() has been terminated with 'index' beeing 11 although it should run until 'index' has the value Long.MAX_VALUE.
Note that the number of iterations until termination may vary, while the index at which the for-loop in getInteger() terminates is always 11.

If the constant in the line marked '(1)' is increased, the number of iterations after which the loop will be incorrectly terminated, decreases.

This error does not happen if the program will be executed with '-Xint'. It also seems to be fixed in 1.5. At least I couldn't reproduce it with 1.5.0-beta2-b51a.

###@###.### 2005-06-06 09:03:59 GMT