United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-7099086 Java Web Start 10.1.* is considerably slower than Web Start 1.4.2, using getresource() repeatedly
JDK-7099086 : Java Web Start 10.1.* is considerably slower than Web Start 1.4.2, using getresource() repeatedly

Details
Type:
Bug
Submit Date:
2011-10-10
Status:
Closed
Updated Date:
2013-12-04
Project Name:
JDK
Resolved Date:
2011-10-28
Component:
deploy
OS:
windows_xp
Sub-Component:
webstart
CPU:
x86
Priority:
P2
Resolution:
Fixed
Affected Versions:
7,7u1
Fixed Versions:

Related Reports
Backport:
Backport:
Backport:
Duplicate:
Relates:

Sub Tasks

Description
Java Web Start 10.1.0.8 (Java SE 7 Update 1) is considerably slower 
compared to Java Web Start 1.4.2, when loading resources by
com.sun.jnlp.JNLPClassLoader.getResource(String) repeatedly.

                                    

Comments
verified with 8 b108 
output
Loaded classes 99 in 1141mills, loaded files 99 firsttime in 213mills second time in 130mills

                                     
2013-12-04
EVALUATION

Problem seem to be related to inefficient processing of indexed jar files.
More research is needed to identify best solution.

Suggested workaround: do not index jar files.
                                     
2011-10-11
EVALUATION

Here is what happens:
   1) Test application uses jar index
   2) Test application consists of many jar files (100) that share same package names. Every jar has just one class in "test" package and 1000 other jar entries.
   3) Test app tries to load classes from "test" package one by one.
   4) Current implementation in DeployURLClassPath (and in fact URLClassPath
       but this needs to be addresses on JDK side) performs validation of the jar index in case index points to jar as candidate to contain requested resource but resource is not found.
   5) validation procedure checks jar has at least one entry in the requested
      package. In the test scenario this means we iterate through 1000
      entries in jar before we find index is ok. And we repeat it for every
      false positive jar (remember they all have "test" package).

Total cost of "validation" for this scenario is 100*1000*(100/2)=5 000 000 jar entries read
(calculated as numberOfLookups*CostOfLookupInOneJar*AverageJarsToLookIn)

This is obviously expensive and real customer app is even bigger (1000+ jars) =>  possible even more expensive.

On other hand the value of this validation check is questionable
(originally was added in 2001, 1.3 timeframe).
The only outcome we get different exception instead of ClassNotFound.
In any case attempt to load class will fail. In case of malformed index
it will file with RuntimeException and apps may not be catching it.
Anyway, check does not seem to worth it.

Suggested fix is to remove validation check. With this change time for second stage
of test is reduced to about 100ms (from 10000ms) and this is comparable with what is reported for 1.4.2
                                     
2011-10-11



Hardware and Software, Engineered to Work Together