517962 - Don't use synclaunch for plugin processes

Status: RESOLVED DUPLICATE of bug 998863

(Core :: IPC, defect)

Description

[Benjamin Smedberg]

Currently plugin instantiation triggers synchronous launching of the plugin process. This is unacceptable and needs to be an asynchronous launch.

Comment 1

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

(In reply to comment #0)
> This is unacceptable and needs to be an asynchronous launch.

Why?  What metrics do you have in mind?

Comment 2

[Benjamin Smedberg]

The startup of a plugin process may take longer than 100ms, which is roughly the amount of time that a user would notice UI becoming unresponsive. I'm assuming that we can't get plugin process startup under that amount of time.

Comment 3

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Just measured on my fast machine, and it was 0.57s cold-start (!!).  Definitely worth doing when we can get some cycles from someone familiar with modules/plugin, i.e. who knows how to make modules/plugin async.

The way it's structured now, there would be little point in loading the plugin module+process in dom/plugins (IPC) async, because modules/plugin immediately thereafter asks the newly loaded module to create an instance, and creating an instance also has to remain sync to avoid restructuring modules/plugin.

Comment 4

[Benjamin Smedberg]

Indeed. Josh/jst: where might be a good place to insert "making plugin instantiation asynchronous" into the plugin host?

Comment 5

[Johnny Stenback (:jst)]

If we do this we'll need a mechanism to block the chrome process and wait for the child process to start up. The case where we'll need that is if a webpage creates an <embed> tag and sets it up to load flash or whatever, then inserts it into the DOM it can call scriptable methods on that plugin right away, and I've seen sites do this. And also, if a webpage touches window.java.lang.xyz, we instantiate a dummy Java plugin right then and there, and that's what exposes properties dirctly to the webpage in that case (which is what LiveConnect was replaced with), and that case will actually create two child processes since the Java plugin runs the dummy applet out of process as well. But in the case where we're just loading a stream as a result of seeing <embed src="..."> in a webpage, we could of course start the plugin process asynchronously and just feed it data once the process is up n' running.

I suspect doing something like this will take some significant work in nsObjectLoadingContent and nsPluginHost, and maybe some in nsObjectFrame as well, but I don't know of any one obvious spot where this all needs to start. One thing we'll need for sure (AFAICT) is new APIs to nsPluginHost to start instantiation and notifications for when it's done, and code to accumulate data coming off the network while we're waiting for the plugin process to start and then pump the data to it once it's up (which may need to be done async as well).

Comment 6

[Benjamin Smedberg]

Are you sure? When I've been writing mochitests doing that exact sequence (dynamically creating an <embed> and inserting it into the DOM) I am never able to script it immediately and have had to wait for instantiation on an event, see http://mxr.mozilla.org/mozilla-central/source/modules/plugin/test/mochitest/test_crashing2.html?force=1#34

I filed bug 536443 to give script a way to watch plugin instantiation and make sure that the page onload was delayed until plugins were instantiated.

In any case, window.java will definitely force us to block, which isn't hard, just annoying. We should discuss tomorrow at the Lorentz meeting whether we want to do this now, or just focus on making startup time not suck.

Comment 7

[Florian Bender]

Is this a dupe of Bug 998863?