Name: tb29552			Date: 05/18/2004


FULL PRODUCT VERSION :
java version "1.4.2_02"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_02-b03)
Java HotSpot(TM) Client VM (build 1.4.2_02-b03, mixed mode)

ADDITIONAL OS VERSION INFORMATION :
Windows NT Version 4.0

A DESCRIPTION OF THE PROBLEM :
We recently faced a peculiar perf prob at a customer site.  The jsp application of the customer was responding very slowly. It would sometimes take 10-12secods to respond for a page with a table showing data.

After a trying all the standard methods of analysing perf, we tried doing verbosegc. The output showed that times when the server took longer to respond, it was doing GC mostly. Tuning the GC params didnt help much. Trying the server mode didnt help much. We finally tried with IBM JDK and it worked fine.

Later by commenting code line by line, we realized that the problem was because of the try-finally blocks int eh generated servlet. The jsp compiler was generating lot of try finally block in the jspService method. Some how this is affecting the GC performance. And some how IBM jdk seems to handle this situation well.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Below are two classes SimpleFinally and  Finally. Both do same operation and same number of times. However SimpleFinally takes forever to complete. Note the GC output. SimpleFinally takes 20ms while Finally takes 2s. Also running the same test on IBM JDK shows not significant diff between the two classes.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The response time for SimpleFinally and Finally should have been same.
ACTUAL -
The response time for Finally was orders of magnitude higher that that of SimpleFinally.

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
------
import java.util.*;

public class SimpleFinally
{
    public static void main(String argv[])
	throws Exception
    {
	long t = System.currentTimeMillis();
	List l = new ArrayList();
	for(int i=0; i<600*1000; i++){
	    	try{
		    l.add("Test"+i);
		}finally{
		    l.clear();
		}
	}
	System.out.println("Time taken: "+(System.currentTimeMillis()-t));
    }
}
------


   Class Finally.java is too large to fit in the Description
   of a bug report.  Refer to attached file Finally.java.Z.

   The abbreviated version looks like this:

import java.util.*;

public class Finally
{
    public static void main(String argv[])
	throws Exception
    {
	long t = System.currentTimeMillis();
	List l = new ArrayList();
	for(int i=0; i<1000; i++){
	    try{
		    l.add("Test"+i);
	    }finally{
		    l.clear();
	    }
	    try{
		    l.add("Test"+i);
	    }finally{
		    l.clear();
	    }

	    [ ... 598 more try ... finally ... blocks deleted ...]

	}
	System.out.println("Time taken: "+(System.currentTimeMillis()-t));
    }
}

---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
Keep the number of try-finallies in a method to the minimum. The prob seems to be related to only TryFinally blocks. Replacing the Try-Finally with regular block seems to work fine.
(Incident Review ID: 269858) 
======================================================================