Bug ID: JDK-6276307 javac consumes too much memory generating stackmap in extreme cases

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

JDK 6
6 b85Fixed

Javac failed with -target 6 or -target cldc on the attached test case. If I use default (without -target 6 or -target cldc) test pass:

--------------------------------------------------
code too large for try statement
            } catch ( classLoad001_04RuntimeExceptionToCatch mpre_N1 ) {
              ^


The system is out of resources.
Consult the following stack trace for details.
java.lang.OutOfMemoryError: Java heap space
        at com.sun.tools.javac.jvm.Code.emitStackMap(Code.java:1219)
        at com.sun.tools.javac.jvm.Code.emitop(Code.java:348)
        at com.sun.tools.javac.jvm.Code.emitop1w(Code.java:884)
        at com.sun.tools.javac.jvm.Items$LocalItem.load(Items.java:380)
---------------------------------------------------

The first error is a separate issue. The OutOfMemoryError indicates that javac runs out of java heap space when allocating type arrays in stackmap. 

###@###.### 2005-05-25 23:58:40 GMT

======================================================
This bug cause following split_verifier  test failed. 
nsk/split_verifier/stress/classLoad/classLoad001_04
nsk/split_verifier/stress/tryCatchFinally/tryCatchFinally001_160
nsk/split_verifier/stress/tryFinally/tryFinally001_240
nsk/split_verifier/stress/multipurpose/multipurpose001_08
nsk/split_verifier/stress/tryCatchFinally/tryCatchFinally001_100
nsk/split_verifier/stress/tryFinally/tryFinally001_160
nsk/split_verifier/stress/tryCatchFinally/tryCatchFinally001_050
nsk/split_verifier/stress/tryFinally/tryFinally001_080
nsk/split_verifier/stress/return/return001_10
nsk/split_verifier/stress/classLoad/classLoad001_09

You can find tonga tlog here.
http://vmsqe.sfbay/nightly/TL/results/1.6.0-auto-200b/ServerVM/SOLSPARC/mixed/SERVICE/nsk.split_verifier-TLNIGHTLY-SERVICE-ServerVM-mixed-SOLSPARC-2005-07-21-11-59-36/analysis.html

###@###.### 2005-07-22 01:06:30 GMT
###@###.### 2005-07-22 01:22:17 GMT

EVALUATION This bug is a regression because the test works in -target 5 but fails in -target 6. Since javac default target has been changed from -target 5 to -target 6, it is also a regression in the behavior of javac when run without an explicit -target option. We will fix the OutOfMemoryError in Mustang. However, the tests will still fail with error message "code too large for try statement". This error is caused by the elimination of jsr/ret in the new class file format. The tests need to be modified (6418723).

27-04-2006

EVALUATION This problem is only seen in questionable VM stress tests of StackMapTable attributes. Theorectically, it would be preferable if javac can compile the exact same programs with -target 6 as with -target 5. However, do to elimination of jsr/ret, certain degenerate programs can exhaust limits in the class file format. Similarly, certain degenerate programs can cause the compiler to generate too many and too big stack maps and thereby exhaust memory. While we should try to do better in such cases, there is no immediate cause for concern as we judge this problem unlikely to affect any customer's real programs.

22-07-2005

EVALUATION We will investigate possible ways to reduce memory consumption during code generation when stackmaps are needed. ###@###.### 2005-05-25 23:58:40 GMT

25-05-2005