On 2013-02-04 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.)
Yeah, part of this code should be "easily" movable to an external
library (by easily, I mean, much eaiser than many other things.)
Unfortunately, I am mostly a post-libxul Mozillian, so it would be better to
have the XPCOM old-timers weigh in on the difficulty of having multiple
libraries in Gecko. I guess the problem with splitting is that almost
everything depends on XPCOM which is at the bottom of the libxul dependency
tree. So, if we try to split things from the bottom, the first thing we'd have
to move is XPCOM. But then we have to deal with internal vs. external XPCOM
interfaces. Because I didn't have to deal with that issue before (which was
pre-libxul), I cannot estimate how much effort and/or how much performance cost
(e.g. relocation overhead) that would have. Also, I am not sure how much the
internal vs. external issue was to deal with the need for a stable ABI vs.
solving other problems like relocation overhead. Definitely we wouldn't need to
have the stable ABI requirement for a split libxul, so perhaps the internal vs.
external issue wouldn't be as painful as before? Also, from looking at
a few pa
rts of the code, it looks like we're already having to deal with this internal
vs. external API problem to a certain extent for WebRTC. I do agree that this
would be a non-trivial project.
A big part of the problem is that exporting C++ classes across modules
is a pain, so in the past we used to put everything behind XPCOM
interfaces, so that we could call into the code using the vtable at
runtime as opposed to statically. Moving everything inside libxul has
allowed us perform huge cleanups by removing unneeded XPCOM interfaces,
etc. It also lets you benefit from compiler optimizations such as
inlining, devirtualization, etc.
Cheers,
Ehsan
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
