JDK-4493074 : Performance problem due to a bailout of the compiler for nested exceptions
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 1.3.1
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • OS: solaris_8
  • CPU: sparc
  • Submitted: 2001-08-16
  • Updated: 2002-03-29
  • Resolved: 2001-08-21
Related Reports
Relates :  
Description

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) 
======================================================================

Comments
EVALUATION The fix for this requires rewriting the parser, which we have done in Merlin. ###@###.### 2001-08-21
21-08-2001