statically link JS engine, provide a proxy shared library

NEW
Unassigned

Status

()

Core
JavaScript Engine
9 years ago
11 months ago

People

(Reporter: gal, Unassigned)

Tracking

Trunk
x86
Mac OS X
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

9 years ago
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.

Updated

9 years ago
Depends on: 525013
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?
(Reporter)

Comment 2

9 years ago
-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

9 years ago
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.
(Reporter)

Comment 5

9 years ago
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.)
(Reporter)

Comment 8

9 years ago
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.
(Assignee)

Updated

4 years ago
Assignee: general → nobody
You need to log in before you can comment on or make changes to this bug.