274089 - Incorporate mozjs in libxul

Status: VERIFIED WONTFIX

(Core Graveyard :: Embedding: GRE Core, defect)

Description

[Benjamin Smedberg]

Darin says brendan says that it's ok to incoroporate libmozjs.so into libxul.so
instead of having it separate. I still believe we should dllexport the
spidermonkey symbols because they are a stable/frozen api that might be useful
to embedders.

Comment 1

[Benjamin Smedberg]

Attachment: Statically link spidermonkey into libxul

Comment 2

[Brendan Eich [:brendan]]

I may have spoken too soon, or been unclear.  People use libmozjs.so (Linux
name, etc. elsewhere) already.  Too many folks build SpiderMonkey from its
standalone makefile or project file, which is archaic and hard.  If a large
number of so-far silent consumers of libmozjs.so find that it goes away at some
future milestone, and that libxul.so (whatever we call it) is too big, they'll
holler.

Separate from this issue, I said it was ok to fold SpiderMonkey into libxul.so
for efficiency, and that we could release libmozjs.so too as a matched
component, for major milestones and releases.

The one thing I did say clearly was that the JS_PUBLIC_API and JS_FRIEND_API
entry points should *not* be exported from such a libxul.so.  They're not part
of the XPCOM-interfaced XUL or Gecko APIs.  They must be exported from libmozjs
and per the above suspicion that there is a non-trivial silent libmozjs user
community, we'll keep exporting them from libmozjs.

In any case, saying that the JS API exports "might be useful" is *not* a reason
to include them.  As Niklaus Wirth said, the trick in design is to leave things
out.  We should stick to what *must* be included in libxul for any app,
including Firefox and Thunderbird, to be built as a front end.  Such apps do not
require the JS API, AFAIK, and should not.

/be

Comment 3

[Mike Shaver (:shaver emeritus)]

Any apps which want to use nsIXPCScriptable's hooks for script-friendlier
helpers will need access to the JSAPI EXPORTs, and possibly FRIENDs.  Calendar
is one such app (we have jsDate conversion magic on calIDateTime).

Comment 4

[Benjamin Smedberg]

I'm happy enough to leave libmozjs.so as a separate sharedlib; I don't see any
significant performance gain by incorporating it into libxul. I will have to
hack up some -rpath-link magic.

But I'm very surprised by "Such apps do not
require the JS API, AFAIK, and should not." I always thought the JS API was a
first-class member of the mozilla embedding story. I firmly believe that if we
were to incorporate spidermonkey into libxul directly, we should still provide
the dllexports. They are a stable/frozen API, needed for script helpers,
venkman, and probably for other purposes.

Please mark WONTFIX unless there's something I'm missing.

Comment 5

[Brendan Eich [:brendan]]

Shaver's got it, I was forgetting about nsIXPCScriptable and his team's work.

If we don't mind having libmozjs.so and the same code in libxul.so, matched
versions, identical JS_* exports from both for any given matched version, then I
withdraw my objection.

It still seems a bit odd, and if you could prove that we gain X% on Ts, Txul, or
Tp by linking SpiderMonkey within libxul, instead of keeping it a separate
DLL/DSO, then I'd be happier.

/be

Comment 6

[Benjamin Smedberg]

There is no possible gain, WONTFIX.

Comment 7

[Brendan Eich [:brendan]]

Benjamin, are you sure?  Maybe not on Linux, due to ELF/GNU drain bamage, but on
Windows, intra-library calls from the rest of libxul into the JS_* entry points
would be faster than inter-library calls into the latter.  That should be a goal
for Linux's toolchain, too.  Was this WONTFIXed too fast?

/be

Comment 8

[Benjamin Smedberg]

Windows does not have the intra-library penalty that unix has, because it does
static relocations instead of a symbol lookup table. The only performance affect
this could have on windows would be to reduce Ts because of DLL-loading
penalties, but that cost is minimal for a library like spidermonkey that exports
a small number of C symbols.

Besides which, including two copies of the code will cause more problems than it
solves, because spidermonkey makes use of function-pointer comparisons which
will no longer hold when there are two copies of functions floating around. The
only other alternative I see is to create a stub library like we do for XPCOM,
but that causes an extra indirection.

I'm willing to be proved wrong by measurements, but pulling in spidermonkey is
not necessary for the big gains I want out of libxul; I don't want to get hung
up on it.

Comment 9

[Darin Fisher]

I agree.  Let's cross this bridge only if we have to.


> The only other alternative I see is to create a stub library like we do for 
> XPCOM, but that causes an extra indirection.

You'd still have to solve the function address uniqueness problem.

Comment 10

[Brendan Eich [:brendan]]

Benjamin, thanks -- that's what I thought, I wanted to make sure I wasn't
winning too easily here.  Thanks for playing devil's advocate (or making me do
that for the original intent of this bug).

One thing I don't want in any scenario is a case where two copies of the JS
engine code would need to be linked into any one app, but I hope we could avoid
that.  Still, if there are two versions in two distinct libraries, Murphy sez
they'll end up linked into one program when we can least afford to deal with the
problem.  So it's good to leave this bug WONTFIX.

/be