On 2/4/2013 4:27 PM, Brian Smith wrote:
Ehsan Akhgari wrote:
Brian Smith wrote:
2. AFAICT, we did not seriously investigate the possibility of
splitting things out of libxul more. So far we've tried cutting
things off the top of the dependency tree. Maybe now we need to try
cutting things off the bottom of the dependency tree.
Can you please give some examples? Let's remember the days before
libxul. It's hard to always make sure that you're accessing things
that are properly exported from the target library, deal with
internal and external APIs, etc.
Any of the non-XPCOM code (most of it imported?) like ipc/ a huge chunk of the
underlying code for WebRTC. (I know we already are planning to split out that
WebRTC code from libxul.)
The big problem didn't really have anything to do with XPCOM. It had to
do with the number and kind of relocations and calls. Relocations were
(and I believe still are) pretty expensive on many systems. The details
differ on ELF/Mach-O/PE, but it shows up the most on ELF systems, so
I'll discuss that in most detail. On ELF systems, calls against
hidden-visibility symbols in the same shared library can be made with
relative addressing and do not require any relocation. Calls against
default-visibility symbols in other libraries requires functions to load
the GOT (typically in the function prolog) and then the calls happen via
an indirect jump which the processor typically cannot predict.
libxul reduced the number of PLT jumps from about 400k to about 15k and
made it so that most gecko functions never load the GOT address in their
prolog. It decreased code size by about 6%, and this improved runtime
performance by about 5% (all of these stats are from memory, I'm not
sure whether the original data still exists). It also reduced the number
of relocations by about 50%, improving startup time by 2%.
Both Mach-o and PE are more efficient formats that don't use a PLT, so
they didn't have the same runtime cost associated with inter-library
calls. But the compiler can still generate more efficient code using
relative addressing for intra-library calls; the windows codesize from
libxul improved by about 1.5% and the runtime performance was improved
by about 1%.
If you have modules that are behind a C (not C++) API, the number of
exported symbols is typically minimal (you can count them), and it's
probably relatively safe to move that code to a separate shared library.
But since C++ APIs typically have many more symbols and those symbols
are sometimes small functions used more in more places, the cost of
relocations is far higher.
So basically the line for what we included in libxul was not precisely
"stuff that used XPCOM" but "stuff that used C++ APIs". The internal
XPCOM string API happens to be the most pervasive C++ API, so it became
a natural dividing line for many things.
I haven't read webRTC at all, so I can't comment on the relocation load
from splitting it off, but the IPC code is very C++-heavy and I fear
that we'd end up with lots of functions making cross-library calls
again, and suffer the codesize/performance costs associated with that.
--BDS
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
