JDK-4690509 : Sybase Java Application startup time is SLOW in JDK 1.4 compared to JDK 1.3.1_02
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 1.4.0
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_nt
  • CPU: x86
  • Submitted: 2002-05-23
  • Updated: 2012-10-08
  • Resolved: 2002-09-02
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.
Other
1.4.2 mantisFixed
Related Reports
Relates :  
JDK-4679390 - sun.misc.Unsafe needs to bind to new JVM native methods
Relates :  
JDK-4653558 - Java Application startup time is SLOW in JDK 1.4 compared to JDK 1.3.1_02
Relates :  
JDK-4616656 - Need a more portable way to unsafely access fields in JDk 1.4
Relates :  
JDK-4717079 - Sybase Java Application startup time is SLOW in JDK 1.4 compared to JDK 1.3.1_02
Relates :  
JDK-4693297 - Performance regression in sun.misc.Unsafe 64-bit restructuring
Description
This is a continuation of bug # 4653558

Sybase Java Application startup time is SLOW in JDK 1.4 compared to JDK 1.3.1_02

Customer Problem Description:
----------------------------

----
We have noticed here that jdk 1.4 starts our applications slower than
Jdk 1.3.1 did.  In fact we have found it to be about 50% worse.  I
thought I had heard that startup time was improved with JRE 1.4.

I have attached a log file that shows my results for one application.  I
compared different java compilers, jar indexing, and the 1.3.1_02 and 1.4
VMs.

Are these the results I should be expecting when comparing 1.3.1_02 with
1.4?

I have attached a sample application which shows this behavior

Unzip it into a directory.  PerfTest2 is the batch file
that runs everything.  You will have to change:
 set jdk=1.3.1_02 to match your machine.

PerfRun.bat assumes that your jre's are installed with the naming pattern
c:\jdk followed by the setting for jdk in PerfTest2.bat.

Note: I run the test once and throw the results away.  Then I run it again
- that way everything should be in memory.

In our case jdk_1.3.1_02_13.log is the same as jdk_1.3.1_02_13c.log
as we only run with Sun's javac compiler.


(See attached file: perfTest2.log)

Note: We haven't tested this application on Sparc platforms. But, if the
performance problem does show up on Sparc, please fix it as we have
customers using our application on Sun's UltraSparc servers.
-----
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: mantis mantis-b02 FIXED IN: mantis mantis-b02 INTEGRATED IN: mantis mantis-b02
14-06-2004
EVALUATION See bug# 4653558 --------------------------- The cost of the LinkedList-related operations which are new in 1.4 has been investigated by modifying Class.java to use a custom growable array implementation ("MethodArray") as a helper for privateGetPublicMethods(). This has no impact on the startup time of the Sybase application. ###@###.### suggested looking at allocation profiles using hprof to see where additional garbage may be being created, in particular by the new reflection implementation. The MethodArray change eliminated the LinkedList-related temporaries from the allocation profile. It was noticed that there were substantially more garbage java.lang.reflect.Field instances created in 1.4.1 than in 1.4.0. The sun.misc.Unsafe.staticFieldBase() rewrite for 4679390 and 4616656, and its use by sun.reflect.UnsafeStaticFieldAccessorImpl, was the culprit. Fixing this minor problem decreased the startup time measurably, though not to 1.4.0 levels on the Windows platform. (On Solaris, the same application starts up slightly faster on 1.4.1 compared to 1.4.0.) Based on this observation, Class.getMethod() was restructured to avoid fetching all public fields for all superclasses and superinterfaces, which was being done in the current implementation for simplicity (i.e., getMethod() was implemented in terms of getMethods()). This moved java.lang.reflect.Method() down the allocation profile. The above two modifications brought the startup time down on a Win2k machine with a ~500 MHz processor from 3.7s to about 3.4s, a roughly 8% gain in run time. In comparison, JDK 1.4.0 starts the application in about 3.2s and JDK 1.3.1 in 2.2s. A test was done to reimplement Class.getMethod() in terms of the old native-code reflection implementation (in which the code which searches for the method is in the VM rather than in the Java libraries.) In order to make this work with the higher-performance bytecode-based reflection implementation in 1.4 the entire reflection package would have to be restructured. The gain for this change was only about 1.5% of the run time of the application and I do not think it is worth the effort and additional complexity to pursue this route. The fixes above (modulo the native-code Class.getMethod() rewrite) will be sent out for review. ###@###.### has noticed that additional time is going into class loading, garbage collection and compilation relative to earlier releases; it is anticipated that several small gains like this one will be required to bring the startup time down to an acceptable level. ###@###.### 2002-05-24 To summarize: the UnsafeStaticFieldAccessorImpl fix is a one-liner and should definitely go into 1.4.1 as it is a regression from 1.4.0. The Class.getMethod() rewrite (and the associated restructuring of Class.getField()) eliminates reflection completely from the profile and I recommend putting it into 1.4.1 RC after it has passed the suite of reflection regression tests (which have not yet been run on the new code.) Again, the reflection restructuring reduces startup time by about 8% for this application and will probably not address the entire escalation. ###@###.### 2002-05-28 After speaking with ###@###.###, I am committing this bug to hopper-beta so it comes up at the bug review meeting tomorrow. ###@###.### 2002-05-28 At the review meeting it was decided that the one-line fix for the sun.misc.Unsafe-related performance regression will be put back for 1.4.1 (see 4693297) but that the rest of the reflection performance improvements will be deferred until 1.4.2. ###@###.### 2002-05-29 The Class.getMethod() and Class.getField() speedups have been put back into the TL integration workspace for 1.4.2. More information is in the comments. ###@###.### 2002-05-29
29-05-2002