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
|
Java