JDK-6668037 : Slow client JVM initialization at applet launch time
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 6u10
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2008-02-26
  • Updated: 2010-09-08
  • Resolved: 2008-06-27
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
6u10 b21Fixed
Related Reports
Relates :  
JDK-6678929 - Slow client JVM initialization at applet launch time (2)
Relates :  
JDK-6714877 - plugin2 printing is not working - CNFE sun/plugin2/main/client/WPluginEmbeddedFrame
Relates :  
JDK-6675834 - (Nightly) : Some of the Liveconnect scenarios are making browser to hang when run with new Plug-in
Relates :  
JDK-6697433 - b23- java console content isn't initially well formatted with OOPP
Description
The user experience of the applet launch time shall be at least very close to the performance of the legacy plugin.

A new client JVM is launched in case that no suitable JVM is running,
which would satisfy the to be launched applet.

Launching and initializing a new client JVM currently takes about 2 seconds, 
which is not acceptable and above the legacy startup time.
Comments
SUGGESTED FIX 6668037 : Slow client JVM initialization at applet launch time Details, see: 'src/plugin/share/classes/sun/plugin2/doc/Applet2StartupTime.txt' Results: *** 2015 ms JVM starup time boost *** - Removing the costly Trace.flush() boosts the startup time about ** 1800 ms ** - Replacing JavaRunTime.initEnvironment() with the only necessary initialization - Replacing AppletViewer.loadPropertiesFiles() - boosts startup time about ** 100 ms **, Where the specific codepath is reduced by 200 ms. - Fast path for : CacheUpdateHelper.updateCache() call - boosts startup time about ** 115 ms ** - extracting the condition IF(Config.getBooleanProperty(Config.JAVAPI_UPDATE_KEY)) out of the new process, so the new process is created only, if necessary! - Show Console costs about 299 ms, i.e. +79% of the startup time, compared to no SHOW Applet Stop behavior: - Reduced STOP_TIMEOUT to 200ms ! Experience shows that until AppContext.dispose() only 10ms were consumed. Therefor the phenomenon of a slow applet stop() is related to the AppContext destruction, for which we don't wait longer than STOP_TIMEOUT - 10ms. +++ Proper DeployPerfUtil initilization and generic PerfHelper - initialize DeployPerfUtil, if enabled - using a generic PerfHelper implementation for non Windows - no native Unix implementation, which does anything yet - using nanoseconds if JRE>=1.5, else milliseconds - storing and showing time in microseconds
16-03-2008
SUGGESTED FIX See CR 6675834, where the Fix is implemented! Results: *** 2015 ms JVM starup time boost *** - Removing the costly Trace.flush() boosts the startup time about ** 1800 ms ** - Replacing JavaRunTime.initEnvironment() with the only necessary initialization - Replacing AppletViewer.loadPropertiesFiles() - boosts startup time about ** 100 ms **, Where the specific codepath is reduced by 200 ms. - Fast path for : CacheUpdateHelper.updateCache() call - boosts startup time about ** 115 ms ** - extracting the condition IF(Config.getBooleanProperty(Config.JAVAPI_UPDATE_KEY)) out of the new process, so the new process is created only, if necessary! - Show Console costs about 299 ms, i.e. +79% of the startup time, compared to no SHOW
15-03-2008
EVALUATION Slow JVM startup time degrades the user experience for OOPP applet, since loading applet's as additional web content shall not disturb the user experience.
15-03-2008