JDK-6651507 : Implement named pipe transport for Windows
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 6u10
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: windows
  • CPU: generic
  • Submitted: 2008-01-17
  • Updated: 2016-01-07
  • Resolved: 2008-06-16
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 b13Fixed
Related Reports
Relates :  
JDK-6659079 - Intermittent teardown and relaunch of applets using named pipe transport
Relates :  
JDK-6661386 - Passing illegal command-line arguments to applets causing browser hangs
Relates :  
JDK-6659002 - Clean up unused shared memory transport
Relates :  
JDK-6678865 - Long command lines or applet parameter lists break new plug-in on Windows
Description
The current shared memory transport used by the new plug-in between the in-browser code and attached JVM instances is inefficient. Because we didn't have enough time to fully debug the "optimized" code paths, the amount of memory traffic and unnecessary signalling of the other side is very high. A transport using named pipes and minimal buffering should be implemented. This should both simplify the code and improve its performance. This may also immediately solve performance issues which appear to be present in the LiveConnect and printing code paths.
Comments
SUGGESTED FIX http://sa.sfbay.sun.com/projects/deployment_data/6u10/6651507.0
04-02-2008
EVALUATION The new Java Plug-In on Windows uses a custom message-passing inter-process communication mechanism between its browser-side code and the attached JVM instances. This message-passing system may be built on top of an arbitrary transport layer. Up to this point, the new Java Plug-In on Windows has used a shared memory transport for the message-passing subsystem. It was hypothesized that the shared memory transport might not be as efficient as desired. Early on, bugs were found in the shared memory transport which caused certain optimizations to be disabled. Essentially, for every byte of data written to or read from the shared memory segment, four bytes (a write or read counter) had to be written, which is clearly inefficient. While there was no glaring performance problem, poor performance of the new printing code for the new Java Plug-In motivated investigation of a transport based on named pipes. A transport implementation has been built on top of Windows named pipes, which is very similar to the Unix socket implementation. Some undocumented behavior of the Windows APIs forced two named pipes to be used, one for writing and one for reading. A persistent error of one of the ConnectNamedPipe calls required a workaround. Other than that the new transport implementation is clean and is much less code than the shared memory transport. Performance numbers comparing the old plug-in, the new plug-in with the shared memory transport, and the new plug-in with the named pipe transport follow. For this LiveConnect microbenchmark the new named pipe transport is roughly twice as fast as the shared memory transport. The conversion from the overly complex OJI to the new NPRuntime as the interface to the scripting engine in Firefox is the reason for the vast performance improvement on that browser. On IE, the performance penalty for the out-of-process plug-in is roughly a factor of two for no-op LiveConnect calls; this is simply the price we have to pay for improved reliability. Old Java Plug-In, IE 7: Time for 20000 Java-to-JavaScript downcalls = 1.111 seconds Time for 20000 JavaScript-to-Java upcalls = 1.603 seconds Time for 20000 Java-to-JavaScript round trip calls = 2.523 seconds New Java Plug-In, IE 7, shared memory transport: Time for 20000 Java-to-JavaScript downcalls = 5.518 seconds Time for 20000 JavaScript-to-Java upcalls = 4.626 seconds Time for 20000 Java-to-JavaScript round trip calls = 10.145 seconds New Java Plug-In, IE 7, named pipe transport: Time for 20000 Java-to-JavaScript downcalls = 2.243 seconds Time for 20000 JavaScript-to-Java upcalls = 2.383 seconds Time for 20000 Java-to-JavaScript round trip calls = 4.266 seconds Old Java Plug-In, Firefox 3: Time for 20000 Java-to-JavaScript downcalls = 2.764 seconds Time for 20000 JavaScript-to-Java upcalls = 36.263 seconds Time for 20000 Java-to-JavaScript round trip calls = 22.061 seconds (During the "upcall" test, the browser opened up a dialog box twice indicating that the script might be unresponsive, and asking whether I would like to terminate or continue it) New Java Plug-In, Firefox 3, shared memory transport: Time for 20000 Java-to-JavaScript downcalls = 5.498 seconds Time for 20000 JavaScript-to-Java upcalls = 11.567 seconds Time for 20000 Java-to-JavaScript round trip calls = 17.355 seconds New Java Plug-In, Firefox 3, named pipe transport: Time for 20000 Java-to-JavaScript downcalls = 2.353 seconds Time for 20000 JavaScript-to-Java upcalls = 4.997 seconds Time for 20000 Java-to-JavaScript round trip calls = 7.821 seconds
04-02-2008