JDK-6186747 : javac performance regression
  • Type: Enhancement
  • Component: tools
  • Sub-Component: javac
  • Affected Version: 1.4.2_08,6
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic,solaris_8
  • CPU: generic,sparc
  • Submitted: 2004-10-29
  • Updated: 2010-05-11
  • Resolved: 2005-03-19
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 b29Fixed
Related Reports
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Description
javac performance has severly regressed since 1.4.2. 

We noticed this first because deployment of applications within the application server regressed when the application server moved to using 1.5. J2EE applications include JSP files that are precompiled and generated EJB classes that are compiled. We see up to a 10% regression in deployment time on the appserver. [Deployment time includes many other operations than compiling -- actual compilation time is worse, as I explain next.]

Actual compilation performance seems to be about 45% worse. I gathered up a the SPECjAppServer 2002 benchmark (about 300 java class files) and compiled it with 1.4.2_06 and 1.5. I tried a variety of 1.5 options (-source 1.2/1.4/1.5; -target 1.2/1.4/1.5 etc.). Tests were run on single CPU and multiple CPU machines running Solaris/Sparc, Solaris x86, Windows 2003 and Linux. In general, it took 45% longer to compile these classes with 1.5 than 1.4.
###@###.### 10/29/04 17:21 GMT

Comments
SUGGESTED FIX http://javac.sfbay/home/pv149515/REVIEWS/6186747/webrev/
14-03-2006

EVALUATION So far, reproducible tests cases have only shown a performance regression less than 30%. While this is not ideal, this appears to be a request for enhancement. Given the level of changes required for tiger, a performance regression of 30% is not surprising. So far the only obvious candidate for this performance problem is the support for CLDC style stackmaps. Even when these stackmaps aren't generated, the compiler still simulates the VM state. We are currently investigating if this can be avoided and if so the performance improves. We very interested in hearing about situations where the performance regression is more substantial than 30%. We need reproducible test cases that include: 1. The complete javac command line required to demonstrate the performance problem. Please, no ant build files. 2. The complete set of dependencies. If that is undesireable, detailed instructions of where to download the dependencies including details on one specific version which exibits the problem. 3. A detailed describtion of how to unpack/install the dependencies. 4. Please measure the performance regression based on multiple runs, generally the first two or three runs shouldn't be considered. 5. Try using the -verbose switch unless it ruins your measurements. Please notice that while -source 1.4 would suggest that support for all 5.0 features can be disabled, that is not the case. Since the J2SE libraries are using the new language features, the compiler must be aware of these features even when compiling 1.4 sources. ###@###.### 2005-1-25 02:40:40 GMT By changing how jar files are indexed and addressing a minor performance bottleneck in codegen, I have reduced the regression from approx 35% to around 9% when compiling SPECjAppServer. I intend to close this issue once these changes have been integrated. However, the profiling data show remaining performance problems for type checking (Attr) and code generation. We suspect that the code generation performance problems could be caused by added complexity for split verifier support. Also, the data seems to indicate that resolveMethod is a potential bottleneck which should be examined further. Finally, some of this is caused by a performance regression in the platform. I have not yet been able to pinpoint the cause of the problem, execpt that it is not the JVM. It could be increased size of rt.jar, string sharing, or something third. ###@###.### 2005-03-03 08:43:40 GMT
25-01-2005

WORK AROUND Here is some general advice which improves javac performance: * Sometimes the VM ergonomics introduced in 5.0 conflict with javac performance, see bug 5023037. Try adding the -client option when running javac. * Every new Java release increases the size of rt.jar which impacts startup time negatively (see 4770745). Prefer compiling as many files as possible with a single javac command over invoking javac multiple times (i.e. once for each source file). * Make sure that the files are local (see 4770745). Especially, don't write class files to NFS. I don't think this advice will solve the submitters problem but I'm mentioning it here anyways for the benefit of others. ###@###.### 10/29/04 23:06 GMT
29-10-2004