JDK-6566201 : JNLP ClassLoader performance degraded in 1.6 significantly for the signed(?) jar
  • Type: Bug
  • Component: deploy
  • Sub-Component: webstart
  • Affected Version: 6
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2007-06-06
  • Updated: 2011-02-16
  • Resolved: 2007-11-28
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 JDK 7
6u10 b08Fixed 7Fixed
Related Reports
Relates :  
JDK-6595845 - Java 6 JavaWebstart increases footprint by factor 2
Relates :  
JDK-6630608 - cannot load applet / application with NULL manifest
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.
02-11-2007
EVALUATION more and more people is running into this bug according to the javalobby forums. needs to be fixed in 6u5.
01-10-2007
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.
06-06-2007