848616 - Add Add-on Manager API to get memory usage for a given addon

Status: RESOLVED INACTIVE

(Toolkit :: Add-ons Manager, defect)

Description

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Bug 846019 will make it so compartments belonging to extensions are identified as such. Would be good to provide a simple Add-ons Manager API using that, to get memory usage for a given add-on.

Unfortunately, fetching this info from the reporters isn't terribly performant, nor is it async. So the API needs to not make this a footgun - ie, a function, not a property. 

Something like Addon.getMemoryUsage() - which would return an object describing the info.

Comment 1

[Justin Lebar (not reading bugmail)]

What do you want to use this API for?

Comment 2

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Just so its clear: This would basically just be a convenience wrapper, it doesn't really add anything new. I can see this being a common pattern that would otherwise require the same verbose boilerplate code to get the info from the memory reporters directly.

As for use-cases:

For awhile now I've been thinking about adding some kind of developer mode or UI to the Add-ons Manager that would bring together various settings, information, and tools to help add-on developers. 

And in general, this API would make it *extremely* simple for things like FHR to include memory usage information for each add-on (assuming it can be made performant enough), or to automatically suggest disabling a memory-hungry add-on when we detect the application isn't running well.

All of which would be possible without the API, but the API would make it much simpler to implement.

Comment 3

[Justin Lebar (not reading bugmail)]

Having a wrapper API around the memory reporters sounds fine to me, if you'll use it.  If we don't have per-compartment JS memory reporting, then it might make more sense to have a function which gets you the memory used by all add-ons at once.

> For awhile now I've been thinking about adding some kind of developer mode or UI to the Add-ons 
> Manager that would bring together various settings, information, and tools to help add-on 
> developers.

This sounds like a good use-case.

> And in general, this API would make it *extremely* simple for things like FHR to include memory 
> usage information for each add-on (assuming it can be made performant enough)

It's the perf that's going to be the main issue, I think.  Even if we had per-compartment reporters, we wouldn't necessarily want to run them automatically since for large add-on compartments, the reporters might be slow.

But we can play around with this; maybe it's not much worse than a compartment GC.  I feel like every time we surface data to devs and users, we find problems, so the more data we can surface, the better.

Comment 4

[Nils Maier [:nmaier]]

You should take into account that there is still a massive number of overlay-based add-ons around, having all their code not in JSM or bootstrap.js (or CommonJS) modules but overlay scripts. These overlay scripts are effectively invisible, as the memory will be allocated from/in the compartments of the XUL being overlaid, so usually you will see browser.xul memory usage going up with no real way to detect what add-ons in particular contribute to that.

You could probably fix that by having globals (and compartment-per-global) for these overlay scripts, but that would break compatibility in a lot of places because all of a sudden there are lots of cross-compartment wrappers. Stuff like expandos not being cross-compartment visible. There was a similar situation when JSMs and Sandboxes went compartment-per-global. However JSMs were mostly used by advanced add-on authors while Sandboxes was kinda Jetpack/SDK only besides some notable exceptions like Greasemonkey, so expert-level folks. Overlay script would however in particular affect the beginner-level add-on authors who likely would have a much harder time figuring out why stuff broke and what to do about that.

That's my two cents from experience by having reviewed hundreds of add-ons for AMO.

What I'm meaning to say it that any per-addon memory reporting right now can only be incomplete at best and may actually incorrectly shine the "warning" spotlight on the wrong add-ons if not done carefully.
This might be to alarmist at this early stage, but you don't want history like this to repeat: http://adblockplus.org/blog/binary-xpcom-components-are-dead-js-ctypes-is-the-way-to-go#c004084

Comment 5

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Oh, yes - I know. I'd planned to add a warning in the documentation for this API stating it doesn't/can't show the whole picture. And there's been plenty of discussion around *not* automatically marking/calling out add-ons based solely on automated reporting - because its just not possible to get it accurate or reliable enough, nor include the whole picture. If/when we get around to doing that sort of thing, it needs to be based off human decisions. But automating some collection can help inform/prompt those discussions, or prompt being more proactive about gathering more data.

Comment 6

[:Irving Reid (No longer working on Firefox)]

Bug 990729 will help a lot with this.

Comment 7

[BMO Automation]

Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.