191035 - First Javascript to Java applet call is slow

Status: RESOLVED INCOMPLETE

(Core Graveyard :: Java: OJI, defect)

Description

[Martin Krieger]

User-Agent:       Mozilla/5.0 (Windows; U; Win98; de-AT; rv:1.2.1) Gecko/20021130
Build Identifier: Mozilla/5.0 (Windows; U; Win98; de-AT; rv:1.2.1) Gecko/20021130

First access to a method in a java applet is much slower than a second one.

Reproducible: Always

Steps to Reproduce:
1. Load attatched file - if possible use a slow machine
2. (Optional) In Java Console, press 5
3. Press the button
4. Press the button again
Actual Results:  
The fist time the button is pressed it took a while for the message to display.
The second time it is much faster.

Expected Results:  
Same speed on all accesses.

The problem also occures on "real" applets - the java.applet.Applet in the
sample is just to keep it simple.

The problem also occures on Windows XP.

On fast systems the delay is shorter.

The java console shows (after pressing 5):

Java(TM) Plug-in: Version 1.4.1_01
Using JRE version 1.4.1_01 Java HotSpot(TM) Client VM
Trace level set to 5: basic, net, security, ext, liveconnect ... completed.
JavaScript: calling Java system code
JavaScript: default security policy = http://localhost
JavaScript: calling Java system code
JavaScript: default security policy = http://localhost
JavaScript: calling Java system code
JavaScript: default security policy = http://localhost
JavaScript: calling Java system code
JavaScript: default security policy = http://localhost
JavaScript: calling Java system code
JavaScript: default security policy = http://localhost

[... lots and lots of this messages ...]

JavaScript: calling Java system code
JavaScript: default security policy = http://localhost

Comment 1

[Martin Krieger]

Attachment: Testcase

Comment 2

[Boris Zbarsky [:bzbarsky]]

Sounds like we lazily initialize some stuff on the first LiveConnect access...
That is as it should be.  What problems is this causing?

Comment 3

[Phil Schwartau]

LiveConnect initializes the JVM when requested to do so.

Reassigning to OJI; cc'ing Patrick. I think we began initializing
Java lazily due to bug 26516, "Java/plugins initialize at startup"

Comment 4

[Martin Krieger]

> LiveConnect initializes the JVM when requested to do so

But as the applet is already loaded I think the JVM is initialized. 

It is not good for the user to wait that long after a button-click (Over 15 
seconds on my system when loading the page as file and over 5 when loading via 
http). IE works imediately.

Comment 5

[Kyle Yuan]

->me

Comment 6

[Kyle Yuan]

*** Bug 187649 has been marked as a duplicate of this bug. ***

Comment 7

[Harm Meijer]

Same on win 2k version 1.5 final with Java Plug-in 1.4.2_04 for Netscape 
Navigator. 

The call is not slow in my case the call never returnes. here is part of the 
trace:


Starting applet ...
JavaScript: calling Java system code
JavaScript: default security policy = http://bugzilla.mozilla.org
JavaScript: calling Java system code
JavaScript: default security policy = http://bugzilla.mozilla.org
JavaScript: calling Java system code
... goes on forefer untill I close mozilla then I get:
Stopping applet ...
Unregistered modality listener
Joining applet thread ...
Destroying applet ...
Disposing applet ...
Joined applet thread ...
Quiting applet ...
Finding information ...
Releasing classloader: sun.plugin.ClassLoaderInfo@110c31, refcount=0
Caching classloader: sun.plugin.ClassLoaderInfo@110c31
Current classloader cache size: 1
Done ...
yet some thread must still be runnint because 
JavaScript: calling Java system code
JavaScript: default security policy = http://bugzilla.mozilla.org
... goes on forever untill I kicked mozilla.exe from task manager then Mozilla
and the java console closes.

Got another test case attached (win2k.zip) with the log (trace set to full)

Comment 8

[Harm Meijer]

Attachment: win2k.zip

Reproduce to show that javascipt to java doesnt work with w2k sp3 mozilla 1.5
and java Plug-in 1.4.2_04 for Netscape

Comment 9

[Harm Meijer]

w2k sp3 mozilla 1.6 final and java Plug-in 1.4.2_04 for Netscape Same problem

Comment 10

[Harm Meijer]

Correction to my post "the call never returnes". It does but with full tracing
on it takes much more that 20 seconds.

Am I correct in assuming that SUN will pick this up? (gotta download 1.5 and
check)

http://developer.java.sun.com/developer/bugParade/bugs/4518207.html

Comment 11

[Kyle Yuan]

Even jre 1.5 can not fix it. This slowness is in mozilla side - liveconnect code
reflects all the java method at the first time, hundreds java methods will be
reflected, that will take too much time. We are trying to fix it with a new
design of liveconnect. Hopefully we can make it in jre1.5.1 and mozilla 1.9/2.0.

Comment 12

[Steven Michaud [:smichaud] (Retired)]

(In reply to comment #11)

Could you tell me where in the Mozilla source code these methods are
reflected?  I consistently experience the problems reported here on
Win2K SP4 with JRE 1.4.2 or 1.5.0 and either Mozilla 1.7.5 or Firefox
1.0.  But the same simple JavaScript-to-Java LiveConnect works just
fine on OS X (using the Java Embedding Plugin and its MRJ Plugin JEP
http://javaplugin.sourceforge.net/) -- no delay at all, even the first
time.  Maybe the "method reflection" doesn't take place on OS X ... or
maybe something else is going on.  (I haven't tested on Linux or
Solaris.)

Here's some evidence that the "method reflection" doesn't take place
on OS X (when using the JEP and MRJ Plugin JEP):  Even with the Java
Console's "tracing level" set to 5, no Java-generated debug messages
(e.g. "JavaScript: calling Java system code" or "JavaScript: default
security policy = http://bugzilla.mozilla.org") appear there when
doing simple JavaScript-to-Java LiveConnect.

Comment 13

[Steven Michaud [:smichaud] (Retired)]

(Following up comment #12)

> Here's some evidence that the "method reflection" doesn't take place
> on OS X (when using the JEP and MRJ Plugin JEP):  Even with the Java
> Console's "tracing level" set to 5, no Java-generated debug messages
> (e.g. "JavaScript: calling Java system code" or "JavaScript: default
> security policy = http://bugzilla.mozilla.org") appear there when
> doing simple JavaScript-to-Java LiveConnect.

Oops ... this _isn't_ evidence that the "method reflection" isn't
taking place on OS X (with the JEP and MRJ Plugin JEP).  Unlike the
OJI Plugin, the MRJ Plugin JEP doesn't use
sun.plugin.liveconnect.SecureInvocation (which is what displays all
those messages).  (In its place the MRJ Plugin JEP uses its own
netscape.oji.LiveConnectProxy class.)

My original question still stands, though.

Comment 14

[Kyle Yuan]

(http://lxr.mozilla.org/seamonkey/source/js/src/liveconnect/jsj_method.c#515)

Please refer to the jsj_ReflectJavaMethods in jsj_method.c. It needs 4 jni calls
for only one method reflection. The jni call is very expensive in Sun's java
plugin implemetation, not sure about Mac's.

Comment 15

[Steven Michaud [:smichaud] (Retired)]

(In reply to comment #14)

Thanks for the info!

jsj_ReflectJavaMethods() seems to work just the same on OS X as it
does on Windows:  It's called just once on an applet (on the applet's
class) the first time you connect to it using JavaScript-to-Java
LiveConnect, but that single call generates _lots_ of JNI calls.  (I
found this out by adding printf calls to jsj_ReflectJavaMethods() and
building my altered jsj_method.c into a debugging version of Mozilla
1.7.5 for OS X.)

However, the MRJ Plugin Carbon (upon which my MRJ Plugin JEP is based)
seems to be orders of magnitude more efficient in its handling of
these JNI calls than Sun's Netscape-4-style and OJI-style plugin
libraries (NPJPI150_01.dll and NPOJI610.dll).  Things are so bad that
I consider this a bug in these libraries.  At least one other person
agrees with me:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5097873

But Sun has closed this and marked it "not a bug".  Like you, they
seem to be waiting for a change in the LiveConnect architecture to
make the initialization of JavaScript-to-Java LiveConnect more
efficient.  I agree that, with the right kinds of architecture
changes, jsj_ReflectJavaMethods() could be made much more efficient --
for example, it'd be nice if the Java plugin libraries supported a
single "initializeLiveConnect" call.  But these kinds of changes
involve several independant parties ... which means they usually take
a long time.

In the meantime, I suspect Sun could really do a much better job.  I
don't know to what extent you are Sun's representative in this matter.
But if you have the time (and are interested), you might want to take
a look at the MRJ Plugin Carbon's code.

By the way (in case you didn't already know it), I'm the Java
Embedding Plugin's author.  And what I call the "MRJ Plugin JEP" is
based on Mozilla.org's MRJ Plugin Carbon
(http://www.mozilla.org/oji/MRJPluginCarbon.html (CFM build),
ftp://ftp.mozilla.org/pub/mozilla.org/camino/releases/MRJPlugin.gz
(Mach-O build), and also bundled with the Mozilla source distro).  I
don't know who wrote the original "MRJ Plugin"
(http://www.mozilla.org/oji/MRJPlugin.html), but it seems that Patrick
Beard ported it to the Carbon environment, and is responsible for its
very efficient handling of JavaScript-to-Java LiveConnect.  My own
contribution (what makes the MRJ Plugin JEP different from the MRJ
Plugin Carbon) was to add support for the Java Embedding Plugin and to
fix a lot of bugs (LiveConnect, in particular, was unusably buggy, at
least in the Mach-O build -- so much so that it's turned off in
Camino's Mach-O distro cited above).

The heart of the MRJ Plugin Carbon's (and MRJ Plugin JEP's)
JavaScript-to-Java implementation is sendMessageToJava() in
CSecureEnv.cpp.  To see how its security model works (and it does have
a good one), look at createClassLoader() and the ProxyClassLoader
class in ProxyClassLoaderFactory.java, and the LiveConnectProxy class
(in LiveConnectProxy.java).

Comment 16

[Steven Michaud [:smichaud] (Retired)]

(Following up comment #15)

> The heart of the MRJ Plugin Carbon's (and MRJ Plugin JEP's)
> JavaScript-to-Java implementation is sendMessageToJava() in
> CSecureEnv.cpp.  To see how its security model works (and it does
> have a good one), look at createClassLoader() and the
> ProxyClassLoader class in ProxyClassLoaderFactory.java, and the
> LiveConnectProxy class (in LiveConnectProxy.java).

One more thing:  What ties these two elements together is
GetLiveConnectProxy() in CSecureEnv.cpp (it's called from
sendMessageToJava() and it calls ProxyClassLoaderFactory.
createClassLoader()).

Comment 17

[Pete Zha]

mass reassign to Alfred

Comment 18

[Dan Swaney]

I'm having a similar problem.  I was planning to posting a separate ticket;
however commenting here might reach the right people faster.

One of my coworkers discovered that the MRJPlugin.jar's ProxyClassLoaderFactory class includes the line:
    System.out.println("<<< " + message + " >>>");

This displays tons of output to the Java Console that can't be turned off without modifying the source for MRJPlugin.jar and rebuilding it.

I'm using Firefox 2.0.0.14 with Java 1.5's Plugin.jar to allow Java Applets to callback Javascript functions and vice versa.  Here's an example of what appears in the Java Console repeatedly as applet-to-javascript calls are made:

<<< ProxyClassLoader: defined LiveConnectProxy class. >>>
<<< Here're the permissions you've got: >>>
<<< java.security.Permissions@b614d0 (
(java.net.SocketPermission 127.0.0.1 connect,accept,resolve)
)

Does anyone know if there is a good site keeping up with the latest MRJPlugin.jar releases?

Comment 19

[RNicoletto]

WFM with Firefox 5.0 on Windows XP and Java 1.6.0.26.

Comment 20

[Benjamin Smedberg]

Mass-closing bugs in the "OJI" component: OJI plugin integration was replaced with npruntime long ago, and these bugs appear to be irrelevant now. If there is in fact a real bug that remains, please file it new in the "Core" product, component "Plug-ins".