JDK-7118421 : RFE: JNLPClassLoader to use hashmap instead of ArrayList
  • Type: Enhancement
  • Component: deploy
  • Sub-Component: webstart
  • Affected Version: 6u29,7u1
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: windows
  • CPU: x86
  • Submitted: 2011-12-06
  • Updated: 2013-10-17
  • Resolved: 2012-01-17
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.
7u4Fixed 8 b22Fixed
Related Reports
Relates :  
Relates :  
JNLPClassLoader uses data structure ArrayList and linear loops to work off
the list of jar files for a given Java Web Start application.

While this may work fine for small numbers of jar files, it won't scale and
for this reason it won't perform well for larger numbers.

Verified with b111(checked for regressions)

EVALUATION Gist of the changes: 1) Convert to URL to strings once and reuse them in String form (new utility method in the URLUtil) This helps to reduce cost of subsequent comparisons 2) Cache String representation of jar URL in the jar desc (query it often) (I did not convert all of use cases this time but we could convert more as we touch those areas) 3) Use maps for lookups of "known" urls instead of iterating over list For my artificial test (see comments) that creates JNLPClassloader with 10000 URLs and then looks up 5000 random URLs (existing) performance was: Average INIT: 1945 Average RES: 1316.1 Now: Average INIT: 341.3 Average RES: 82.9 Where INIT is construction time, RES is total lookup time (in ms). Measurement done based on average of 10 runs of test case. Of course impact on real app will be not so significant (as my test is essentially stress test) and on other hardware numbers may vary.

EVALUATION Clearly JNLPClassloader and some underlying logic can be improved a bit and it will have some impact on performance of applications with a lot of jars. However, it seem unlikely to explain 27% slow down observed by customer. I've created small test that has 10000 of URLs in the JNLPClassloader and performs 5000 lookups and it only takes few hundred milliseconds for lookups on my laptop. I'll work on some tweaks to improve performance but it is will not change things dramatically. Would it be possible to get profile dumps from their real app? Ideally both - dump in the sampling mode and profile mode. It might also help to get full list of URLs they have in the JNLPClassLoader. I've noticed that population of classloaders cause DNS lookups for all referenced hosts and if DNS server is not available/slow then it slows things down a lot.