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. 

  xxxxx@xxxxx   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

  xxxxx@xxxxx   2005-07-22 01:06:30 GMT
  xxxxx@xxxxx   2005-07-22 01:22:17 GMT
Posted Date : 2005-07-22 01:22:17.0

N/A

We will investigate possible ways to reduce memory consumption during code generation when stackmaps are needed. 

  xxxxx@xxxxx   2005-05-25 23:58:40 GMT
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.
Posted Date : 2005-07-22 16:33:52.0

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).
Posted Date : 2006-05-02 21:41:57.0