Performance/MemShrink/Meetings/2011-08-16
From MozillaWiki
< Performance | MemShrink
Contents
Updates on ongoing work
- njn found a huge clownshoes issue, which has now been approved for beta. 700mb on some pages.
- Bug 678376 shows off this clownshoes issue very well. Generally, it is a good stress test for DOM and layout, but not a very representative page. In Comment #13 of this bug, bz has a great breakdown of what is showing up in DMD.
- jemalloc
- pbiggar: jemalloc on 32-bit OSX doesn't work, and is unfixable. Want to enable for 64-bit, disable for 32-bit, but Unify, which creates the universal binary, doesn't like that.
- khuey: has talked to the jemalloc people about upstream changes, ball is in our court for Windows jemalloc (this was about moving to a more recent version?).
- Jetpack. What can we do to help Jetpack? Gabor Krizsanits (Jetpack team) is investigating two Memshrink-related bugs right now (Bug 677294 and some other one). He is new, so he'd like some help with these bugs and isn't sure who to talk to. jst suggested Blake or Andreas if they have time, or anybody from jsengine who knows about compartments. Gabor will start with Blake.
- JS fragmentation: mccr8 talked to billm about a compacting collector. Not a quick fix, but it would help a lot with JS heap fragmentation, which seems to be a big problem.
- sfink is working on tools to interactively debug what the JS roots are (Bug 677949). He is also working on the very beginnings of a low-level tool to dig around and try to find references to a pointer in memory. Similar to what roc and Kevin Gadd have worked on.
Reporting memory bugs
- Ehsan raised the issue that when he's reporting memory bugs, he's not sure what to include. He doesn't have a lot of info about what is happening with his profile and whatever else. Just puts about:memory info in, bugs don't really go anywhere. What useful information would help?
- njn said you should list your addons, see if you can reproduce it in safe mode. Standard bug reporting things.
- Ehsan said these issues don't always show up in a second run, so it isn't clear what to do then. If he can't reproduce it, what then?
- Jesup said there should be a wiki article about reporting a memory leak.
Communication about things users can do to improve memory usage
njn: Might be good to emphasize more how to fix up your profile and deal with addons, as these can be a source of memory problems. Especially with Firefox 7 coming out, where we claim to fix a bunch of memory leaks, if somebody tries it, and still has memory problems due to a busted profile, they will probably give up on Firefox entirely.
Memshrink ideas
- jst added the list of MemShrink ideas to the wiki. He went through the list to filter things out, but most of the ideas don't have associated bugs yet.
- njn is not convinced that getting information out of a non-responsive browser is very useful. sfink said these ideas are mostly useful any time you are reporting memory problems.
- Somebody needs to file a bug on writing memory event logs to disk.
- An intern jez is working on about:memory over time, in bug 472209. atop is similar, at the system level.
- A3: allow you to issue a remote command to dump an about:memory snapshot to a file.
- A4: can be annoying, but may not fix it. sfink: last ditch emergency option to cover people with terrible situations. Tab could close, or kill JS or something. Better than just killing the browser.
- We'll discuss more next week.