Dynamically linking the JS engine has a substantial runtime cost, however, undoing that is not trivial. Extensions and plugins want to load the js dll and talk to it. We should investigate whether it is possible to embed the js engine into the browser executable and then provide a shared library proxy that forwards all function calls from the dll back into the main executable. Alternatively, the js dll could be a symbolic link to the main executable on platforms where that works and export all necessary js symbols.
What is the substantial runtime cost of dynamically linking the JS engine? Do extensions and plugins need to load the JS dll or can they work through XPCOM?
-fPIC is the major runtime cost. I think extensions load the engine directly via the dll. I don't think anyone talks to it via XPCOM, but I might be mistaken. Blake?
Since we don't particularly need to worry about binary compat for this, I don't think we necessarily need a proxy shared library at all, and extensions could just load the symbols directly from the executable. I don't know of that many extensions using raw JSAPI currently, but I've been wrong guesstimating that sort of thing before.
There are definitely extensions that link to mozjs32.dll and such, and there at least used to be plugins that did as well. Plugins may no longer be doing that, in our NPScriptable world, but it would be worth finding out.
I guess we could go ahead with static linking and discover on the way whether we have to wire up the proxy thing.
Let's not face-plant on purpose. /be
Note that we renamed js3250.dll -> mozjs.dll on trunk in a bug whose number I've forgotten at the moment. (Something to do with Win x64 support.)
The renaming should have broken all consumers. I am pleasantly surprised we got away with that.
The bug is bug 469654 - it hasn't shipped yet (trunk only, post-1.9.2).
Yeah, we've only shipped it in an alpha, so I wouldn't think that'd actually reveal any bustage.
You need to log in before you can comment on or make changes to this bug.