Closed Bug 848616 Opened 12 years ago Closed 6 years ago

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

Categories

(Toolkit :: Add-ons Manager, defect)

defect
Not set
normal

Tracking

()

RESOLVED INACTIVE

People

(Reporter: Unfocused, Unassigned)

References

Details

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.
Depends on: 848619
What do you want to use this API for?
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.
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.
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
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.
Bug 990729 will help a lot with this.
Depends on: 990729
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.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.