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 :  
Relates :  
Relates :  
Relates :  
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

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

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