JDK-6862965 : JNLP2ClassLoader is too greedy clonning native libraries
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 6
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2009-07-22
  • Updated: 2013-11-01
  • Resolved: 2009-11-20
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.
6u18 b03Fixed 7Fixed
Related Reports
Relates :  
Relates :  
Relates :  
Plugin classloader creates copy of native library before loading it.
FX runtime has several native libraries and copying of the is actually expensive.

In my experiments (on fast PC) overhead of performing copy for JMC test is over 10%.
For other systems (slower/faster) mileage will vary but it seems impact on startup is significant.

Separating from discussion of whether we could avoid clonning at all (at least for trusted libraries)
there are some other things that can be improved:

1) Do not clone libraries for first client (i.e. lock then in place and copy only if lock is already present)
   This will help benchmarks and may be many real world use cases where user does not run more than 1 FX app at time.

2) Do not copy all libraries at once.
   As of now plugin seems to perform cloning directories and they may contain libaries that will be never used (like we likely only use decora-sse or decora-d3d). This might have some sideffect if system has another lib with same name installed and it will be pulled in as dependency for library being loaded. However, this seems to be imaginary case. In fact pulling system lib in such case might be benefitial as then we can reuse msvcp71.dll and msvcr71.dll if they are available on the system.

3) Explore possible ways to reduce cost of cloning. (symlinks? clonning dll in the memory?)
We still need to follow up to:
  1) plug in jar index support for lazy native libs
  2) see if we can accept sharing of the same native lib between different classloaders.
     This is generally no-no for libs using jni but for java-independent libs it might be good option
      (i.e. MS runtime libs, media codecs, etc.)

EVALUATION findLibrary() logic is update to be: a. iterate through list of known native jars (know at that moment) b. skip jar if it is known to not contain lb in question [NOT COMPLETED: still need to plug in jar index] c. use cached copy of jar if available. download overwise d. if jar does not contain lib we need then continue with next lib e. found jar - [Webstart] stop iterating and return path to copy of the lib in the cache f. found jar [Plugin] - if we are not using lib in this process yet - use lib directly from the cache - otherwise clone and use it - If lib has multiple libraries and is not marked in manifest as "libs are independent" then we process them as single set (either use whole set from cache or clone whole set) - stop iterating and return path to library This mostly resembles previous behavior with few potebntial incompatibilities (e.g. if someone was relying to the fact that all libs are fro all lazy native jars copied at once then it may fail. This is easy to workaround though.)