From:  Eric Rahm <erahm@mozilla.com>
Date:  07 Sep 2016 07:35:50 Hong Kong Time
Newsgroup:  news.mozilla.org/mozilla.dev.memory
Subject:  

Re: MemShrink Pre-Triage (6th Sept 2016)

NNTP-Posting-Host:  63.245.214.181



On Tue, Sep 6, 2016 at 4:16 PM, Andrew McCreight <amccreight@mozilla.com> wrote:


On Tue, Sep 6, 2016 at 4:07 PM, Eric Rahm <erahm@mozilla.com> wrote:

MemShrink triage: 2016-09-06

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

Agenda

(Add name and topic to discuss here)

There was some talk of moving the memshrink meeting time to avoid other conflicts. It looks like for folks who have joined in the past few months Tues at 4pm PDT might work. Let me know if this sounds good. This would be for the next meeting, not this week of course.

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

  • 1290667 - Firefox :: General - Memory usage skyrockets with multiple tabs

    Votes:

    erahm, what do you think?

Close, no feedback from reporter after one month.
  • 1293965 - Core :: General - Memory consumption increases on a page that refreshes (500MB per quarter hour)

    Votes:

    erahm, what do you think?

Waiting on me, I setup a session and will let it run for a few hours. Looks like the site still has some sort of auto refresh every 30 seconds.
  • 1299107 - Core :: JavaScript Engine - Share more shapes across compartments

P2 probably? More minor than the initial work I'm guessing.

P2 sounds fine, Jan has a patch with reviews.
  • Votes:

  • 1299683 - Core :: JavaScript Engine - Memory leak from JSRuntime::init when not on the main thread

This looks like a leak from somebody embedding SpiderMonkey. I removed the tag.
 
  • Votes:

  • 1300173 - Core :: Memory Allocator - facebook causes excessive fragmentation in jemalloc heap


This seems weird but I don't know how actionable it is.

Sounds like a job for the heap profiler. That much bin-unused is sketchy, but as-is we don't support multiple content processes, so ideally other pages would help reduce the fragmentation.

Maybe P3, with an option to upgrade after looking at a profile?
 
 
  • Votes:


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



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