Name: kb87695 Date: 08/16/2001


This is a bug, possibly in the parser, where the compiler bails out with nested exceptions.
Instead of compiling the method, the method keeps getting intrepreted.

This is a shortened version of a customer site application. The function prvided below is called very frequently. It would be nice if the compiler could compile such a method, but it bails out, and we keep on interpreting the method. This makes the application very slow.

Here is the test case. I have commented the sections of the code that is required for it to fail. In the first case, the method gets deoptimized, although it is in the second try that it bails out.


This is the version string of the java_g that I used.
$ java_g -server -version
java version "1.3.1" Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1-b24)
Java HotSpot(TM) Server VM (build 1.3.1-b24-debug, mixed mode)

Please run it with the options described below.

$ java_g -server -XX:-Inline -XX:+PrintOptoBailouts -XX:+TraceOptoParse -XX:+PrintCompilation -XX:+TraceDeoptimization -XX:CompileThreshold=10 -Xcomp -XX:CompileOnly=.nextmethod Test


// Test.java
// java_g -server -XX:-Inline -XX:+PrintOptoBailouts -XX:+TraceOptoParse -XX:+PrintCompilation -XX:+TraceDeoptimization -XX:CompileThreshold=10 -Xcomp -XX:CompileOnly=.nextmethod Test


class Test {

    public static void main(String argv[]){
int i,j;
i=10;j=20;
foo(i,j);
    }
    public static void foo(int i,int j) {
int k;
for (i=0;i<20000;i++)
nextmethod(i);
    }
    public static void nextmethod(int i) {
int retval;
Tag tag = null;

        // NEEDS 2 levels of try's to FAIL
try {
//stuff
tag = null;
try {
tag = new Tag();
                // NEEDS the "if ..... throw" lines to FAIL
retval = tag.doStartTag();
if (retval == 2) {
throw new Exception ("An exception occurred!");
}
retval = tag.doEndTag();
if (retval == 5)
return;
}
catch (Exception e1) {
throw new Exception ("Caught exception. Throw again.");
}
finally{
// NEED THIS TO FAIL
System.out.println("finally...\n");
}
}
catch (Exception e) {
return;
}
    }
}

class Tag {
    public int doStartTag () {
return 5;
    }
    public int doEndTag () {
return 5;
    }
}

I am attaching the necessary final output for this bug.
  2 !b Test::nextmethod (89 bytes)
Merging state at bci:0 with empty state on path 1
Parsing block at bci:0 _ready:0, _reached:0, _looped:0
           bci:0 preds:0
           bci:1
           bci:2
           bci:3
           bci:4
Merging state at bci:63 with empty state on path 2 while cloning
           bci:7
           bci:8
Merging state at bci:52 with empty state on path 2 while cloning
Merging state at bci:63 with previous state on path 3 while cloning
           bci:11
           bci:12
           bci:13
Merging state at bci:52 with previous state on path 3 while cloning
Merging state at bci:63 with previous state on path 4 while cloning
           bci:16
           bci:17
           bci:18
           bci:19
Merging state at bci:32 with empty state on path 1
           bci:22
Merging state at bci:63 with previous state on path 5 while cloning
           bci:25
           bci:26
           bci:28
Merging state at bci:52 with previous state on path 4 while cloning
Merging state at bci:63 with previous state on path 6 while cloning
           bci:31
Merging state at bci:52 with previous state on path 5 while cloning
Parsing block at bci:32 _ready:0, _reached:2, _looped:2
           bci:32 preds:0
           bci:33
Merging state at bci:52 with previous state on path 6 while cloning
Merging state at bci:63 with previous state on path 7 while cloning
           bci:36
           bci:37
           bci:38
           bci:39
Merging state at bci:46 with empty state on path 1
           bci:42
Merging state at bci:71 with empty state on path 4 while cloning
Parsing block at bci:46 _ready:0, _reached:3, _looped:3
           bci:46 preds:0
Merging state at bci:71 with empty state on path 4 while cloning
Parsing block at bci:52 _ready:0, _reached:3, _looped:4
           bci:52
           bci:53
Merging state at bci:63 with previous state on path 8 while cloning
           bci:56
           bci:57
           bci:59
Merging state at bci:63 with previous state on path 9 while cloning
           bci:62
Merging state at bci:63 with previous state on path 10 while cloning
Parsing block at bci:63 _ready:0, _reached:2, _looped:4
           bci:63
           bci:65
Merging state at bci:71 with empty state on path 4 while cloning
Parsing block at bci:71 _ready:0, _reached:2, _looped:5
  M J45 bci:71 preds:3
    J45 bci:73
    J45 bci:76
    J45 bci:78
Merging state at bci:86 with empty state on path 2 while cloning
Merging state at bci:86 with previous state on path 3 while cloning
    J45 bci:81
           bci:45
Parsing block at bci:71 _ready:0, _reached:2, _looped:6
  M J68 bci:71 preds:3
    J68 bci:73
    J68 bci:76
    J68 bci:78
Merging state at bci:86 with empty state on path 2 while cloning
Merging state at bci:86 with previous state on path 3 while cloning
    J68 bci:81
           bci:68
           bci:70
Merging state at bci:86
Bailed out: static void Test.nextmethod(jint) due to shared exception handler in/out of jsr...ret
XXX Explicit NULL checks inserted: 10
XXX Explicit NULL checks removed at parse time: 7

Bailed out: static void Test.nextmethod(jint) due to shared exception handler in/out of jsr...ret
  2 COMPILE FAILED

This is a performance issue with the compiler, and this sort of method is used often in application code.

###@###.### 2001-08-16

(Review ID: 129817)
======================================================================