Fwd: Testing compartment-per-addon change

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Fwd: Testing compartment-per-addon change

Kevin Brosnan
Interesting opportunity to get some good bugs logged. Read the forwarded
message below and if you find something check
https://bugzilla.mozilla.org/showdependencytree.cgi?id=1030420&hide_resolved=1
for known bugs in the blocking section if it is new file a bug as
described. If you need some help filing a bug reply to me off list or find
me on IRC as kbrosnan.

Kevin

Kevin Brosnan
---------- Forwarded message ----------
From: "Bill McCloskey" <[hidden email]>
Date: Jun 25, 2014 3:39 PM
Subject: Testing compartment-per-addon change
To: "dev-platform" <[hidden email]>, <
[hidden email]>
Cc:

> Hi everyone,
>
> Brian Hackett, Bobby Holley, and I have been working on some changes to
the way that add-ons run (bug 990729). These changes make possible a lot of
awesome new features for monitoring add-on performance and memory usage
(which I'll talk about below). However, there's the possibility that some
add-ons might break. The changes have landed on nightly but they're hidden
behind a pref. Before we can enable them, I'd like to ask people to enable
the pref locally and do some simple testing. Here's what you need to do if
you'd like to help out:
>
> 1. Get the latest nightly.
> 2. Go to about:config and set the dom.compartment_per_addon preference
(you should see it set to false by default).
> 3. Do whatever you normally do.
> 4. If you notice any abnormal behavior with your add-ons, file a bug
under XPConnect, CC me (:billm), block bug 1030420, and include details
about the add-on and what's going wrong. If something goes wrong, it will
probably be related to global variables attached to the window that can't
be found. However, these errors could manifest in all sorts of ways, so
please look for anything strange.
>
> WHAT IS THE CHANGE?
>
> We're trying to isolate add-on code so that it doesn't run in the same
compartments as normal Firefox code. For add-on code in JSMs and
components, we already do that. Bug 990729 makes it so that code attached
to XUL overlays (<script> elements and inline event handlers) runs in a
different compartment from the Firefox window. Bug 1017310 additionally
makes it so that chrome XBL code runs in a separate compartment as well.
There are still some holes in the scheme, though. Content XBL code isn't
separated out. Flashblock is the only add-on we know of that uses content
XBL, so we're still deciding whether that's worth fixing.
>
> WHAT ARE THE BENEFITS?
>
> Right now there aren't any. However, a lot of cool things should be
possible with these patches:
>
> * Previously, a lot of add-on memory usage was mixed in with chrome code.
With this change, about:memory will be able to completely separate out
memory allocated by add-ons from memory allocated by Firefox. Eventually,
it should also be possible to track how much memory is kept alive by
add-ons--that is, memory that would be released if an add-on weren't
holding on to it.
>
> * Every time we start running code for an add-on, we'll have to go
through cross-compartment wrappers. With the right wrappers, we'll be able
to track how much time we spend running add-on code. This information could
be really useful for the profiler or for telemetry.
>
> * We'll be able to track which APIs are used by add-ons. Searching
mxr.m.o/addons is really useful if you're considering deprecating an API,
but it doesn't tell you anything about non-AMO add-ons. With this change,
we'll be to instrument the browser to report which add-ons are calling a
given API and to report that information via telemetry or something.
>
> * We'll be able to expose a different API surface to add-ons than we do
to the rest of the browser. So we'll be able to deprecate an API in Firefox
but still offer it to add-ons. We'll also be able to hide certain APIs from
add-ons.
>
> * We're going to use this stuff for electrolysis to intercept any add-on
calls that might touch content objects so that we can take an alternate
path. The hope is that we'll be able to make a lot more add-ons compatible
with e10s. This is the original motivation for the bug.
>
> Only the electrolysis stuff is being actively worked on right now. If any
of this other stuff sounds interesting and you'd like to work on it, please
contact me!
>
> HOW DOES THIS AFFECT MEMORY USAGE?
>
> Even though they sound similar, this change shouldn't have anywhere near
the effect on memory that compartment-per-global did. Most users have only
one Firefox window open and only a few add-ons installed so we'll only be
creating an extra 3 or 4 compartments. A typical Firefox user already has
~500 compartments, so this change won't affect the total much.
>
> -Bill
> _______________________________________________
> firefox-dev mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/firefox-dev
_______________________________________________
dev-quality mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-quality