542567 - statically link JS engine, provide a proxy shared library

Status: RESOLVED INCOMPLETE

(Core :: JavaScript Engine, defect)

Description

[Andreas Gal :gal]

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.

Comment 1

[Joel Reymont (:joelr)]

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?

Comment 2

[Andreas Gal :gal]

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

Comment 3

[Benjamin Smedberg]

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.

Comment 4

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

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.

Comment 5

[Andreas Gal :gal]

I guess we could go ahead with static linking and discover on the way whether we have to wire up the proxy thing.

Comment 6

[Brendan Eich [:brendan]]

Let's not face-plant on purpose.

/be

Comment 7

[(not currently active) Ted Mielczarek]

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.)

Comment 8

[Andreas Gal :gal]

The renaming should have broken all consumers. I am pleasantly surprised we got away with that.

Comment 9

[:Gavin Sharp [email: [e-mail]]]

The bug is bug 469654 - it hasn't shipped yet (trunk only, post-1.9.2).

Comment 10

[(not currently active) Ted Mielczarek]

Yeah, we've only shipped it in an alpha, so I wouldn't think that'd actually reveal any bustage.