United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: 6566201 JNLP ClassLoader performance degraded in 1.6 significantly for the signed(?) jar
6566201 : JNLP ClassLoader performance degraded in 1.6 significantly for the signed(?) jar

Details
Type:
Bug
Submit Date:
2007-06-06
Status:
Closed
Updated Date:
2011-02-16
Project Name:
JDK
Resolved Date:
2007-11-28
Component:
deploy
OS:
windows_xp
Sub-Component:
webstart
CPU:
x86
Priority:
P3
Resolution:
Fixed
Affected Versions:
6
Fixed Versions:
6u10

Related Reports
Backport:
Relates:
Relates:

Sub Tasks

Description
FULL PRODUCT VERSION :
1.6.0, 1.6.0u1

ADDITIONAL OS VERSION INFORMATION :
Windows XP Professional

EXTRA RELEVANT SYSTEM CONFIGURATION :
JNLP file is located localy, web-server runs locally for the web-start

A DESCRIPTION OF THE PROBLEM :
Apparently the 1.6 java has different approach inside the JNLP classloader.
The performance profiler shows significant amount of time spent
in the java.util.jar.Attributes.Attributes() and
sun.net.www.protocol.jar.URLJarFile.getManifest().
Same web-start app is taking 7 seconds to start under 1.5u11 and
45 seconds under 1.6.x

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Create jar file with large number of classes (~1k, 10mb jar), sign it
and launch through the webstart (make sure most of your classes need to be loaded at the very beggining, no extensive operations required).


EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
In 1.5 such app would start in few seconds
ACTUAL -
In 1.6 it is much slower

REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER SUBMITTED WORKAROUND :
None, stay on 1.5 Webstart until it is fixed

                                    

Comments
EVALUATION

Instead of returning a copy of the manifest for every single call to getManifest, we construct a CachedManifest object and return that instead.  In this CachedManifest object, we make the manifest entries map, main attributes, and each attributes in the entries map immuatable, so the CachedManifest object is read-only.
                                     
2007-11-02
EVALUATION

more and more people is running into this bug according to the javalobby forums.  needs to be fixed in 6u5.
                                     
2007-10-01
EVALUATION

i can actually see the problem with the testcase.

it is caused by CachedJarFile.getManifest.  Due to secrity reasons, we are returning a copy of the actual manifest.  however, we are doing the copy for every single call to getManifest.  instead, we should just do the copy once, and then always return the copy for subsequent calls.
                                     
2007-06-06



Hardware and Software, Engineered to Work Together