United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6651507 Implement named pipe transport for Windows
JDK-6651507 : Implement named pipe transport for Windows

Details
Type:
Bug
Submit Date:
2008-01-17
Status:
Closed
Updated Date:
2010-09-08
Project Name:
JDK
Resolved Date:
2008-06-16
Component:
deploy
OS:
windows
Sub-Component:
plugin
CPU:
generic
Priority:
P3
Resolution:
Fixed
Affected Versions:
6u10
Fixed Versions:
6u10 (b13)

Related Reports
Relates:
Relates:
Relates:
Relates:

Sub Tasks

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
                                     
2008-02-04
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
                                     
2008-02-04



Hardware and Software, Engineered to Work Together