United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-7173533 Discoverer 10g olap is slower when using java 1.6 than with 1.5
JDK-7173533 : Discoverer 10g olap is slower when using java 1.6 than with 1.5

Details
Type:
Bug
Submit Date:
2012-06-01
Status:
Closed
Updated Date:
2013-04-20
Project Name:
JDK
Resolved Date:
2012-06-20
Component:
deploy
OS:
generic
Sub-Component:
deployment_toolkit
CPU:
generic
Priority:
P2
Resolution:
Fixed
Affected Versions:
6u18
Fixed Versions:
6u33 (b32)

Related Reports
Backport:
Relates:

Sub Tasks

Description
SHORT SUMMARY: There is a noticable performance degradation between
   JRE 5.0uX and JRE 6uX when a web-based Java application uses a lot
   of resource files packed in a single or several big-sized jar files.
 INDICATORS: The test procedures described by the customer require much
   more time to finish with JRE 6uX than with JRE 5.0uX.
 TRIGGERS: The problem happens always with JRE 6uX.
 KNOWN WORKAROUND: No workarounds for JRE 6uX are known. Both plugin1
   and plugin2 demonstrate this issue.
 PRESENT SINCE: JRE 6 ea b38
 HOW TO VERIFY: There is no stand-alone test case for this issue.
   The support team has reproduced the customer's environment and
   provided us with access to their testbed.
 NOTES FOR SE:
 REGRESSION: yes

                                    

Comments
EVALUATION

All the details are available in BugDB:
https://bug.oraclecorp.com/pls/bug/webbug_print.show?c_rptno=13059819

In short, the investigation discovered the following hot spot responsible
for this performance degradation:
sun.plugin.net.protocol.jar.CachedJarURLConnection.connect()
For example, in Test 3 with JDK 6u31 this method consumed 58%
of CPU time (with JDK 5u18 it was about 0%). This is actually pretty close
to the size of the performance regression itself. Here is the problematic
stack trace:

...
java.net.URL.getContent()
sun.plugin.net.protocol.jar.CachedJarURLConnection.getContent()
sun.plugin.net.protocol.jar.CachedJarURLConnection.connect()
sun.net.www.protocol.jar.JarURLConnection.connect()
sun.net.www.protocol.jar.JarFileFactory.get(URL, boolean)
sun.net.www.protocol.jar.URLJarFile.getJarFile(URL,
URLJarFile$URLJarFileCloseController)
sun.net.www.protocol.jar.URLJarFile.retrieve(URL,
URLJarFile$URLJarFileCloseController)
sun.plugin.PluginURLJarFileCallBack.retrieve(URL)
sun.plugin.PluginURLJarFileCallBack$2.run()
sun.plugin.PluginURLJarFileCallBack.access$000(PluginURLJarFileCallBack,
URLConnection, String, boolean)
sun.plugin.PluginURLJarFileCallBack.downloadJAR(URLConnection, String, boolean)
java.io.FilterInputStream.read(byte[])
...

In the current design this operation involves too much disk I/O (called by
sun.plugin.PluginURLJarFileCallBack.downloadJAR()).

The fix is to skip this unnecessary I/O, if the requested JAR file already exists
in Java Deployment Cache.

In JRE 7uX and 8 a more complete solution is already available. It is tracked as
CR 7162188. So, this fix does not need to be forward-ported to JRE 7uX/8.
                                     
2012-06-02



Hardware and Software, Engineered to Work Together