JDK-6349606 : REGRESSION: Bad Performance regression running XMLMark on 5.0_05 versus 5.0_03
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util.jar
  • Affected Version: 5.0u5
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: solaris_10
  • CPU: sparc
  • Submitted: 2005-11-14
  • Updated: 2011-02-16
  • Resolved: 2005-12-22
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
6Resolved
Related Reports
Duplicate :  
Description
FULL PRODUCT VERSION :
1.5.0_05

ADDITIONAL OS VERSION INFORMATION :
It happens on all OSes, e.g. Solaris and Linux.

A DESCRIPTION OF THE PROBLEM :
If you run the DOM1 test from XMLMark (a benchmark written at Sun) then you will see that there is a huge drop in performance at 1.5.0_05 when compared with 1.5.0_03. For example, on my Linux box the number drops from 600 to 350.

Looking at this under a profiler the problem is clear. There was a change to the behaviour of JarFile.getInputStream() so that it always calls the method getManifest(). This is OK in the class JarFile.java, where getManifest() uses a caching mechanism to make sure the manifest is only read once.

On XMLMark, the JarFile class being used is actually the subclass sun.net.www.protocol.jar.URLJarFile. The getManifest() mechanism in this class does not cache the contents of the manifest so it needs to re-read the manifest on every call to getInputStream().

The upshot is that Sun's XMLMark benchmark shows XML performance has degraded sharply in 15.0_05.

Here is a typical stack trace that only exists in 1.5.0_05:

        java.util.HashMap.<init>(HashMap.java:181)
        java.util.HashMap.<init>(HashMap.java:217)
        java.util.jar.Attributes.<init>(Attributes.java:67)
        java.util.jar.Attributes.clone(Attributes.java:274)
        sun.net.www.protocol.jar.URLJarFile.getManifest(URLJarFile.java:119)
        java.util.jar.JarFile.getInputStream(JarFile.java:395)
        sun.net.www.protocol.jar.JarURLConnection.getInputStream(JarURLConnection.java:136)
        java.net.URL.openStream(URL.java:1007)
        java.lang.ClassLoader.getResourceAsStream(ClassLoader.java:1161)
        javax.xml.parsers.FactoryFinder.find(<Unknown Source>:Unknown line)
        javax.xml.parsers.DocumentBuilderFactory.newInstance(<Unknown Source>:Unknown line)
        com.sun.xmlmark.BenchDOM.build(<Unknown Source>:Unknown line)
        com.sun.xmlmark.BenchDOM.runTimeTest(<Unknown Source>:Unknown line)
        com.sun.xmlmark.RunXmlBench.runTimeTest(<Unknown Source>:Unknown line)
        com.sun.xmlmark.driver.Agent.process(<Unknown Source>:Unknown line)
        com.sun.xmlmark.driver.Agent.run(<Unknown Source>:Unknown line)

The problem arises when calling javax.xml.parsers.DocumentBuilderFactory.newInstance, which happens many times in XMLMark. However there may be other situations in which getInputStream() is called on an open XML document, in which case this performance degradation might be seen more broadly than in just this benchmark.



STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Run the java side of the XMLMark benchmark, test DOM1.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Got about 600 transactions per second with 1.5.0_03, should get the same with 1.5.0_05.
ACTUAL -
Only get 360 transactions per second with 1.5.0_05.

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
Sun's own XMLMark benchmark.
---------- END SOURCE ----------

Release Regression From : 5.0u3
The above release value was the last known release where this 
bug was known to work. Since then there has been a regression.

Release Regression From : 5.0u3
The above release value was the last known release where this 
bug was known to work. Since then there has been a regression.

Comments
EVALUATION this bug is being accepted as a performance regression.
21-12-2005