From:  Andrew McCreight <amccreight@mozilla.com>
Date:  05 Dec 2015 06:42:01 Hong Kong Time
Newsgroup:  news.mozilla.org/mozilla.dev.memory
Subject:  

Re: MemShrink Triage (3rd Dec 2015)

NNTP-Posting-Host:  63.245.214.181



On Thu, Dec 3, 2015 at 4:23 PM, Eric Rahm <erahm@mozilla.com> wrote:

Apologies for the double-post, lets triage in this separate thread.

MemShrink triage: 2015-12-03

Triage URL: http://mzl.la/1yYeaGL

Agenda

(Add name and topic to discuss here)

Bug List

Vote for:

  • P1 High importance, will follow up periodically
  • P2 Important issue, possibly already being worked on
  • P3 Real issue, someone will get to it if they have time
  • moreinfo We need logs, or clarifying information
  • invalid Misclassified, remove the MemShrink tag

5 bugs to triage

  • 1220488 - Core :: Audio/Video: Playback - FireFox memory leaks and issues, rampant on a particular site

    Votes:

    erahm, what do you think? I'm leaning P1. 95% heap-unclassified is pretty ridiculous, I think we at least need better reporting here. Additionally it feels like we really shouldn't be using that much memory for videos that aren't actively playing (this would be particularly bad on Fennec/FxOS).


That sounds fine to me. Video can use up lots of memory very fast if something goes wrong.
 
  • 1221503 - Firefox :: General - Firefox is slow (Windows swapping all the time)

    Votes:

    erahm, what do you think? I'm inclined to close this as WFM, I didn't see anything that stuck out as egregious, this feels more like a "Firefox uses more memory than a decade ago" bug.


They are using ABP with a version that doesn't have the ABP memory improvements, so that may be a factor. We could see if they are willing to try that and if they get improvements dupe it over to the style sheets bug. I suggested that in the bug. Beyond that, I don't think it is a great use of time to try to debug somebody's issues who is running a version that is a year or more out of date. "Incomplete" is a better designation than "Worksforme", as they are still experiencing the issue.
 
  • 1224573 - Core :: Audio/Video: Playback - Leak MediaMemoryTracker

    Votes:

    erahm, what do you think? I'm inclined to P2 this. It's possible that the async reporting itself is causing a leak, in that case I might lean towards P1.


Sounds reasonable.
 
  • 1228615 - Core :: Hardware Abstraction Layer (HAL) - [e10s] (Win) Nightly (FF45.0a1) main process use a lot of memory in the last builds (2015-11-25)

    Votes:

    It looks like the reporter is suggesting this is fixed, so probably close WFM.

    mconley pointed out that this might be a regression in session restore on e10s from bug 1209689, that points to a rather large talos regression in bug 1227275, which now that I think of it we should probably MemShrink (discussion further down).

  • 1230110 - Core :: DOM - Leak with in <img>

    Votes:

    Leaning P3, odd usage of html and there's a patch inbound. But it also looks like we want uplift it, so maybe a higher priority is warranted.

    mccr8, what do you think?


This should be P2, because while it is a weird thing for a page to do, it'll leak the entire tab, which is bad. (This is fairly academic as it is already fixed.)
 
  • 1227275 - Firefox :: General - 70-80% e10s sessionrestore regression on fx-team (v.45) on Nov 20, 2015 from push 924d421d766a

    Votes:

    P1. Rather large regression, it's noted that this brings us back in line w/ non-e10s, but this is one of the few areas where e10s has been a memory improvement.

How much of a memory win is this? I agree that if it is a big win, a P1 is appropriate, regression or not relative to e10s.
 

_______________________________________________
dev-memory mailing list
dev-memory@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-memory