FULL PRODUCT VERSION :
1.6_9 1.6_10 1.6_14 1.6_16 and 1.7 (latest as of time of report)

ADDITIONAL OS VERSION INFORMATION :
Windows vista x64 - multuple and windows 2008 - mutiple.

EXTRA RELEVANT SYSTEM CONFIGURATION :
This requires the x64 version of java to be run. No other special considerations are required. It has been shown on multiple machines of different configurations and hardware.

A DESCRIPTION OF THE PROBLEM :
The following cutdown when compiled using standard javac will produce a class file which when run will consume over 2gig of memory once the program has stopped executing (ie after the final println).

The amount of memory consumed is altered by altering the initial value of the variable k. However, changing the number of iterations of the last loop makes no difference other than it must be a loop. Altering the number and referencing of the fields tends to cause the bug to stop. Altering the initial value of i below 14563 causes the bug to go away.

-Xint stops the bug and so we believe it to be in JIT.
-Xmx has no effect - this is almost certainly native memory.

The consumption of memory is so fast that we have seen it overwhelm the OS and cause a machine to be unresponsive of many minutes and in some cases require a reboot.

public class crashJava
{

    public void crashJava()
    {
        // This number must be more than 14562
        for(int j = 14563; j != 0; j--)
        {
        }
       
        // This must reference a field
        System.out.println(i1);

        // The resource leak is roughly proportional to this initial value
        for(int k = 20000000; k != 0; k--)
        {
            if(i2 > i3)i1 = k;
            if(k==(20000000-1))break;
        }

        System.out.println("program ended :)");
    }

    public static void main(String args[])
    {
        (new crashJava()).crashJava();
    }
   
    private int i1;
    private int i2;
    private int i3;
}

Please note - we have tested this on several machines and seen exactly the same behaviour. The consumption of memory has been monitored using process-explorer from Microsoft. Because it happens outside the execution of the java its self, we cannot give any more information at this time.

Thanks -AJ

For any more information please contact me at ###@###.###. This bug was found by members of our language development team.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Compile and run the cutdown supplied using x64 java on windows.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The program will print out two lines of text and execute having consumed minimal resource.
ACTUAL -
The program will run and then when you expect it to exit it will start to consume massive amounts of memory and cpu. If you use -Xprof then this consumption occurs _after_ the profiler information is produced.

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
{

    public void crashJava()
    {
        // This number must be more than 14562
        for(int j = 14563; j != 0; j--)
        {
        }
       
        // This must reference a field
        System.out.println(i1);

        // The resource leak is roughly proportional to this initial value
        for(int k = 20000000; k != 0; k--)
        {
            if(i2 > i3)i1 = k;
            if(k==(20000000-1))break;
        }

        System.out.println("program ended :)");
    }

    public static void main(String args[])
    {
        (new crashJava()).crashJava();
    }
   
    private int i1;
    private int i2;
    private int i3;
}
---------- END SOURCE ----------

Release Regression From : 6u3
The above release value was the last known release where this 
bug was not reproducible. Since then there has been a regression.

Release Regression From : 6u3
The above release value was the last known release where this 
bug was not reproducible. Since then there has been a regression.