Last Comment Bug 563700 - (DarkMatter) [meta] Reduce about:memory's "heap-unclassified" number to (typically) 10%
(DarkMatter)
: [meta] Reduce about:memory's "heap-unclassified" number to (typically) 10%
Status: NEW
: meta
Product: Core
Classification: Components
Component: General (show other bugs)
: unspecified
: All All
: -- normal with 25 votes (vote)
: ---
Assigned To: Nicholas Nethercote [:njn]
:
Mentors:
https://wiki.mozilla.org/Platform/Mem...
: 648411 (view as bug list)
Depends on: 557924 570785 681199 682432 683079 683080 684698 700885 744733 768903 B2GDarkMatter 806377 806379 816598 819690 820133 820134 820242 820244 820248 820899 820900 845179 847787 856443 893865 922098 922100 922102 922106 922430 923298 948329 957498 964031 964043 1007434 1016445 1016680 1016703 1019183 1027551 1032291 1054321 1087093 1241102 1241105 1266187 532486 546477 558467 563701 571249 590790 598875 621810 revampaboutmemory 638549 648490 649867 655363 663271 664486 664913 665995 669116 669117 671150 671297 671299 672755 673158 674721 674818 675132 675136 676457 DMD 676732 677466 677491 677653 677704 678126 678376 678422 678977 682215 682216 682431 682435 684799 684800 688125 697041 697335 698326 698968 699210 699721 699801 699951 700645 701041 702942 704400 704623 704695 704723 705987 707865 708762 709470 712822 716163 NewDMD 722057 722595 723799 726764 729008 729403 736383 740162 746714 747508 747509 747647 752952 765326 765344 784989 788906 795128 799019 810105 810215 811018 811021 811022 813867 820132 820558 820894 820896 820898 820906 822549 826521 826553 850545 858615 884368 893926 922094 922429 923255 923302 946781 946870 948327 961883 964039 967817 985193 986082 1007438 1014584 1015646 1016123 1016345 1047523 1052626 1241096
Blocks: 610165 636220 MemShrinkTools 678940
  Show dependency treegraph
 
Reported: 2010-05-04 10:27 PDT by Vladimir Vukicevic [:vlad] [:vladv]
Modified: 2016-04-20 12:40 PDT (History)
59 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
snapshot of peak memory usage, 10 gmail tabs (268.88 KB, text/plain)
2011-05-02 23:17 PDT, Nicholas Nethercote [:njn]
no flags Details
about:memory from technet.com blog post (8.77 KB, text/plain)
2011-07-20 19:59 PDT, Nicholas Nethercote [:njn]
no flags Details

Description Vladimir Vukicevic [:vlad] [:vladv] 2010-05-04 10:27:54 PDT
This is a tracking bug for the various about:memory reporters that need to be added.
Comment 1 Nicholas Nethercote [:njn] 2011-04-07 18:13:02 PDT
*** Bug 648411 has been marked as a duplicate of this bug. ***
Comment 2 The 8472 2011-04-09 04:19:29 PDT
Here is one testcase that about:memory currently doesn't account for:

1. open any website (e.g. http://google.com)
2. execute the following bookmarklet:
javascript:if(undefined == document.body.asdf){document.body.asdf = []};var a=document.body.asdf;var i,j,tmp;for(i=0;i<10000;i++){tmp=[];for(j=0;j<10000;j++){tmp[j]="a"} a.push(tmp)};alert("done");void(0);

This simply attaches a huge nested array to the DOM tree (yeah, i know, bad practice) and gobbles up about 1GB of memory which doesn't show up in about:memory.

If you don't get the "done" alert the script possibly failed due to an OOM abort, you'll have to close the tab and try again with lower numbers for the loop counts.
Comment 3 Nicholas Nethercote [:njn] 2011-05-02 23:03:37 PDT
JSScripts should be tracked.  With 10 gmail tabs open I saw them account for 17% of the live heap.  Here's one call stack from Massif:

o1o> 17.03% (70,660,318B) 0x67648A4: JSScript::NewScript(JSContext*, unsigned int, unsigned int, unsigned int, unsigned int, unsigned int, unsigned int, unsigne
d int, unsigned int, unsigned int, unsigned short, unsigned short, JSVersion) (jsutil.h:239)
| o2o> 16.64% (69,033,931B) 0x67675CE: JSScript::NewScriptFromCG(JSContext*, JSCodeGenerator*) (jsscript.cpp:1260)
| | o3o> 15.73% (65,262,175B) 0x66DBFCE: js_EmitFunctionScript (jsemit.cpp:3678) 
| | | o4o> 15.67% (65,014,983B) 0x66D9BE7: js_EmitTree (jsemit.cpp:4640)
| | | | o5o> 08.47% (35,117,714B) 0x66D7723: js_EmitTree (jsemit.cpp:6176)
| | | | | o6o> 08.46% (35,109,464B) 0x66D585A: js_EmitTree (jsemit.cpp:5984)
| | | | | | o7o> 08.13% (33,744,883B) 0x66D8622: js_EmitTree (jsemit.cpp:5892)
| | | | | | | o8o> 08.07% (33,496,774B) 0x66D636D: js_EmitTree (jsemit.cpp:5451)
Comment 4 Nicholas Nethercote [:njn] 2011-05-02 23:07:16 PDT
JSObject slots should be tracked, ie. in allocSlots(), growSlots() and shrinkSlots().  With 10 gmail tabs open I saw them account for 7% of the live heap.
Comment 5 Nicholas Nethercote [:njn] 2011-05-02 23:16:11 PDT
Also various strings are important, eg:

o1o> 11.67% (48,410,287B): nsStringBuffer::Alloc() (nsSubstring.cpp:209)
| o2o> 10.55% (43,754,212B): nsXMLHttpRequest::ConvertBodyToText() (nsXMLHttpRequest.cpp:762)
| | o3o> 10.55% (43,754,212B): nsIXMLHttpRequest_GetResponseText() (dom_quickstubs.cpp:26975)
| |   o4o> 10.06% (41,739,008B): js_NativeGet() (jscntxtinlines.h:326)
| |   | o5o> 10.06% (41,739,008B): InlineGetProp() (StubCalls.cpp:1868)
| |   | | o6o> 10.06% (41,739,008B): js::mjit::stubs::GetProp() (StubCalls.cpp:1894)

Not sure how best to record them -- lump all strings together, or try to be smarter than that.
Comment 6 Nicholas Nethercote [:njn] 2011-05-02 23:17:26 PDT
Created attachment 529642 [details]
snapshot of peak memory usage, 10 gmail tabs

Here's the raw data I'm getting these ideas from, BTW.
Comment 7 Nicholas Nethercote [:njn] 2011-05-03 00:08:35 PDT
The Hunspell spell-check accounts for 2.7MB on my machine, it looks like it's a constant amount.  See bug 653817 comment 7.
Comment 8 Nicholas Nethercote [:njn] 2011-05-03 00:27:28 PDT
js::PropertyTable::init() and js::PropertyTable::change() together account for 4.3% in the gmail example.
Comment 9 The 8472 2011-05-24 17:07:09 PDT
My testcase from comment #2 still shows up under heap-unclassified. Considering that it is trivial to use up memory like that and many poorly written javascript libraries attach all their state to dom objects i would say it would be useful to add instrumentation for that case.
Comment 10 Nicholas Nethercote [:njn] 2011-06-16 00:04:45 PDT
(In reply to comment #2)
> Here is one testcase that about:memory currently doesn't account for:
> 
> 1. open any website (e.g. http://google.com)
> 2. execute the following bookmarklet:
> javascript:if(undefined == document.body.asdf){document.body.asdf = []};var
> a=document.body.asdf;var
> i,j,tmp;for(i=0;i<10000;i++){tmp=[];for(j=0;j<10000;j++){tmp[j]="a"}
> a.push(tmp)};alert("done");void(0);

Oh, bug 571249 will fix that.  (Well, the follow-up bug 664647 will do so.)  
I just tried your JS snippet in a build with the js/object-slots reporter enabled (plus per-compartment reporters from bug 661474):

1,624,547,222 B (100.0%) -- explicit
├──1,494,174,525 B (91.97%) -- js
│  ├──1,314,183,902 B (80.90%) -- compartment(http://www.google.com.au/)
│  │  ├──1,310,986,032 B (80.70%) -- object-slots
│  │  ├──────1,436,610 B (00.09%) -- scripts
│  │  ├────────983,040 B (00.06%) -- mjit-code
│  │  ├────────572,112 B (00.04%) -- tjit-data
│  │  │        ├──444,000 B (00.03%) -- allocators-reserve
│  │  │        └──128,112 B (00.01%) -- allocators-main
│  │  ├────────131,072 B (00.01%) -- tjit-code
│  │  ├─────────69,676 B (00.00%) -- mjit-data
│  │  └──────────5,360 B (00.00%) -- string-chars


So that's good! :)
Comment 11 Nicholas Nethercote [:njn] 2011-07-08 03:01:02 PDT
I've changed this back to Core/General;  although the numbers show up in about:memory, the reporters themselves are mostly in Core, and about:memory doesn't need changing for them to show up once they are added.
Comment 12 Justin Lebar (not reading bugmail) 2011-07-12 13:17:50 PDT
Oh, sorry for changing the component without reading this.
Comment 13 Nicholas Nethercote [:njn] 2011-07-12 18:30:09 PDT
I'm changing this bug's title and repurposing it slightly.  Instead of being a simple tracking bug for new reporter's, it's a bug for getting the "heap-unclassified" number (which is currently typically around 35--50%) down as low as feasible.  Obviously, bugs for new reporters will still block this bug.

All of the things identified above have been spun-off into separate bugs (some of which have been fixed) except for the nsXMLHttpRequest strings one in comment 5.

A couple more stack traces of interest from the Massif data:

o1o> 05.00% (20,748,856B)  nsCSSExpandedDataBlock::Compress() (mozalloc.h:229)
| o2o> 04.99% (20,688,600B)  (anonymous namespace)::CSSParserImpl::ParseDeclarationBlock() (Declaration.h:124)
| | o3o> 04.91% (20,371,668B)  (anonymous namespace)::CSSParserImpl::ParseRuleSet() (nsCSSParser.cpp:2612)
| | | o4o> 04.91% (20,349,128B)  nsCSSParser::Parse() (nsCSSParser.cpp:963)
| | | | o5o> 04.91% (20,349,128B)  mozilla::css::Loader::ParseSheet() (Loader.cpp:1585)
| | | |   o6o> 04.86% (20,156,400B)  mozilla::css::Loader::LoadInlineStyle() (Loader.cpp:1807)
| | | |   | o7o> 04.86% (20,156,400B)  nsStyleLinkElement::DoUpdateStyleSheet() (nsStyleLinkElement.cpp:298)
| | | |   |   o8o> 04.76% (19,743,840B)  nsStyleLinkElement::UpdateStyleSheetInternal() (nsStyleLinkElement.cpp:209)


o1o> 03.81% (15,797,388B) nsTextFragment::SetTo() (nsMemory.h:68)
| o2o> 03.81% (15,797,388B) nsGenericDOMDataNode::SetTextInternal() (nsGenericDOMDataNode.cpp:350)
|   o3o> 02.50% (10,366,215B) nsHtml5TreeOperation::AppendText() (nsHtml5TreeOperation.cpp:197)
|   | o4o> 02.50% (10,366,215B) nsHtml5TreeOperation::Perform() (nsHtml5TreeOperation.cpp:531)
|   |   o5o> 02.48% (10,300,277B) nsHtml5TreeOpExecutor::RunFlushLoop() (nsHtml5TreeOpExecutor.cpp:489)
|   |   | o6o> 02.45% (10,160,236B) nsHtml5ExecutorFlusher::Run() (nsHtml5StreamParser.cpp:153)


o1o> 02.92% (12,120,960B) ChangeTable (pldhash.c:563)
| o2o> 02.91% (12,068,864B) PL_DHashTableOperate (pldhash.c:649)
| | o3o> 01.02% (4,233,984B) AddSelector() (nsCSSRuleProcessor.cpp:2608)
| | | o4o> 01.02% (4,233,984B) nsCSSRuleProcessor::RefreshRuleCascade() (nsCSSRuleProcessor.cpp:2715)
| | |
| | o3o> 00.68% (2,839,040B) RuleHash::AppendRuleToTable() (nsCSSRuleProcessor.cpp:528)
| | | o4o> 00.68% (2,822,656B) RuleHash::AppendRule() (nsCSSRuleProcessor.cpp:560)
| | | 
| | o3o> 00.33% (1,367,040B) mozilla::FramePropertyTable::Set() (nsTHashtable.h:188)
| | | o4o> 00.32% (1,329,152B) nsIFrame::GetOverflowAreasProperty() (FramePropertyTable.h:237)
| | | |
| | | o4o> 00.01% (37,888B) in 6 places, all below massif's threshold (00.10%)
| | |
| | o3o> 00.24% (1,009,152B) AppendRuleToTagTable() (nsCSSRuleProcessor.cpp:540)
| | | o4o> 00.22% (897,024B) RuleHash::AppendRule() (nsCSSRuleProcessor.cpp:565)
| | |   
| | o3o> 00.21% (888,832B) nsDocument::AddToIdTable(mozilla::dom::Element*, nsIAtom*) (nsTHashtable.h:188)


o1o> 02.87% (11,917,512B) nsCSSSelectorList::AddSelector() (mozalloc.h:229)
| o2o> 02.87% (11,907,936B) (anonymous namespace)::CSSParserImpl::ParseSelectorGroup() (nsCSSParser.cpp:3644)


o1o> 01.63% (6,742,008B) (anonymous namespace)::CSSParserImpl::ParseRuleSet() (mozalloc.h:229)
| o2o> 01.62% (6,713,136B) nsCSSParser::Parse() (nsCSSParser.cpp:963)
| | o3o> 01.62% (6,713,136B) mozilla::css::Loader::ParseSheet() (Loader.cpp:1585)
| |   o4o> 01.59% (6,613,920B) mozilla::css::Loader::LoadInlineStyle() (Loader.cpp:1807)
| |   | o5o> 01.59% (6,613,920B) nsStyleLinkElement::DoUpdateStyleSheet() (nsStyleLinkElement.cpp:298)
| |   |   o6o> 01.56% (6,488,640B) nsStyleLinkElement::UpdateStyleSheetInternal() (nsStyleLinkElement.cpp:209)


See the attachment for full details.

Looks like we really need some CSS memory reporters!  There were a couple of >1% stack traces for CSS things that I haven't copied in here either.
Comment 14 Nicholas Nethercote [:njn] 2011-07-12 18:38:45 PDT
It was suggested at today's MemShrink meeting that it might be worth someone digging into memory dumps or something else to push this along.  But the relevant information is actually all there in Massif's output.  The hard part of interpreting that output is knowing how the allocation traces Massif reports match up with existing memory reporters.  But a similar problem would occur for anyone who dug through memory dumps.

I think a better way forward would be to identify sites for which our heap-unclassified number is unusually high.  Comment 2 and bug 669005 are both good examples (and both are now fixed).  I know Massif is a pain to run on Firefox, so I'm happy to run it on any such sites that people can find.

Or if you just know of any remaining decent-sized chunks of memory that aren't covered, please speak up.  (Bug 669117 was identified this way by khuey, IIRC.)
Comment 15 Andrew McCreight [:mccr8] 2011-07-13 09:08:04 PDT
If we want a snappy name for this bug, I propose "Dark Matter".
Comment 16 Nicholas Nethercote [:njn] 2011-07-20 19:59:35 PDT
Created attachment 547315 [details]
about:memory from technet.com blog post

On Linux64, if I load just about:memory?verbose and http://blogs.technet.com/b/dmelanchthon/archive/2011/07/19/featurematrix-outlook-client-und-exchange-server-reloaded.aspx, I get a "heap-unclassified" of ~50%.  The next highest bucket is "js" with 32%.  Full output is attached.  That page includes lots of tables.
Comment 17 Andrew McCreight [:mccr8] 2011-07-21 10:54:58 PDT
That actually suggests an interesting approach to tracking down additional darkmatter: automatically check the heap-unclassified numbers for a bunch of webpages, and look at sites that have unusually large numbers to see what is weird about them.

Relatedly, in https://bugzilla.mozilla.org/show_bug.cgi?id=670689#c23 bz says: "And by the way, I'm guessing that in this case the remaining unclassified stuff is also somewhere in the js engine.  Might be worth it to look up where."
Comment 18 Nicholas Nethercote [:njn] 2011-07-21 16:47:05 PDT
(In reply to comment #17)
> That actually suggests an interesting approach to tracking down additional
> darkmatter: automatically check the heap-unclassified numbers for a bunch of
> webpages, and look at sites that have unusually large numbers to see what is
> weird about them.

Yes.  See comment 14 :)
Comment 19 Andrew McCreight [:mccr8] 2011-07-28 23:03:35 PDT
Nice catch with Bug 675132.  Is it possible to use Massif (which I assume is recording the amount requesting of every malloc?) to see how much space is being wasted by allocations-slightly-more-than-powers-of-two?  Or that something you already set up to ferret this out?  The cycle collector allocates memory in chunks, and I could imagine it accidentally wasting a bit of space in the same way, so it could probably be happening all over the place.
Comment 20 Nicholas Nethercote [:njn] 2011-07-28 23:27:41 PDT
(In reply to comment #19)
> Is it possible to use Massif (which I assume is
> recording the amount requesting of every malloc?) to see how much space is
> being wasted by allocations-slightly-more-than-powers-of-two?

Nope.  Massif replaces the heap allocator with its own version, and the amount of rounding-up is a characteristic of the heap allocator.  Well, I guess I could try to get Massif to round up the same as jemalloc, but there's an easier path forward -- see bug 675136 where I've found that jemalloc rounding could be accounting for something like 17% of "heap-allocated", i.e. roughly half of "heap-unclassified".
Comment 21 Nicholas Nethercote [:njn] 2011-07-28 23:37:23 PDT
Just to clarify about Massif: it makes a half-hearted attempt to account for extra space needed by the allocator -- it adds 8 bytes to the amount recorded for each heap block, on the assumption that the average overhead is that size.  You can change it with the --heap-admin option, but it's always a constant.  So it's pretty hopeless.  Also, that overhead-per-block is recorded separately from the requested-amount-per-block and it's not even shown in those allocation trees that I cut and paste into bugs all the time.  So I haven't even considered jemalloc's rounding until just today.

tl;dr:  Massif is hopeless for measuring extra space caused by jemalloc's rounding and book-keeping.
Comment 22 Andrew McCreight [:mccr8] 2011-07-29 08:30:53 PDT
Yeah, I meant doing some kind of post-processing step in Massif to round up the same as jemalloc, but looks like you cut out the middle man.
Comment 23 Nicholas Nethercote [:njn] 2011-08-03 21:46:37 PDT
I was thinking some more about how to get *serious* about hunting down all the heap-unclassified bytes.

You'd add instrumentation code to maintain a data structure that records 1 bit of information for every malloc'd byte.  A 0 means "not reported", a 1 means "reported".  You'd also add instrumentation code to record, for every heap block, the stack trace at its allocation point.

Then, you'd modify every heap memory reporter so that when it is queried, it sets the "reported" bits of all the heap bytes it counts.

Once about:memory was loaded, you'd iterate over all the heap blocks.  Any heap block fully reported would be ignored.  Any heap block partially or not-at-all reported would be recorded.  You'd aggregate repeated stack traces for recorded heap blocks and present the stack traces in order so that the ones responsible for the most unreported bytes are shown first.

Also, while the memory reporters are doing their thing, you'd complain about any byte on the heap whose "reported" bit was set more than once -- such bytes are double-counted.  You could print out its stack trace and the name of the reporter that was second to count it.

Tracking one-bit-per-byte metadata and per-heap-block stack traces is something that Valgrind excels at, BTW.  A Valgrind tool that implemented this analysis would have to use its own heap allocator rather than jemalloc (that's just how Valgrind works), so it would have to be careful about the rounding up of request sizes, but it could definitely be made to work.  Memory reporters would use client requests to tell the tool which bytes have been accounted for.  A client request would also be used to tell the tool when all the memory reporters have been consulted.

There's a fairly obvious candidate for who might implement this :P
Comment 24 Nicholas Nethercote [:njn] 2011-08-04 16:48:31 PDT
I spun the Valgrind tool idea off as bug 676724.
Comment 25 Hugh Nougher [:Hughman] 2011-10-11 17:31:53 PDT
Bug 291643 should be blocking darkmatter as XML produces lots of heap-unclassified
Comment 26 Nicholas Nethercote [:njn] 2011-10-16 20:35:52 PDT
I've set a specific goal of 10% dark matter for "typical" cases, so that this bug has an end goal.  We can argue about the meaning of "typical" when we're getting close.  (With Gmail and this bug open, I currently see 22.93% dark matter.)
Comment 27 Justin Lebar (not reading bugmail) 2011-10-16 21:18:35 PDT
A lot of bugs are of the form "this totally non-typical page generates lots of heap-unclassified."  It seems to me that bugs of that form are still worth tracking (perhaps in a separate bug), since it's hard to understand what we're doing wrong on those pages if about:memory fails us.
Comment 28 Nicholas Nethercote [:njn] 2011-11-05 12:51:43 PDT
Something that bug 699951 made me think of is that there's one situation that's hard to measure with DMD, because it's so slow -- long sessions with lots of browsing.  (I've left DMD running overnight before, but that doesn't involve opening/closing lots of sites.)
Comment 29 Phoenix 2011-12-14 00:11:40 PST
Nicholas, what about Bug 646575?
Comment 30 Nicholas Nethercote [:njn] 2011-12-14 00:40:38 PST
(In reply to Phoenix from comment #29)
> Nicholas, what about Bug 646575?

What about it?
Comment 31 Phoenix 2011-12-14 01:27:21 PST
Sholdn't it be added to this list too?
Comment 32 Nicholas Nethercote [:njn] 2011-12-14 15:41:26 PST
It's unclear to me how bug 646575 relates to this bug.  Can you explain?
Comment 33 Loic 2012-04-04 06:27:05 PDT
Nicholas, do you know if there are some memory reporters for the memory use of plugin-container.exe (I mean especially about Flash/Java/Silverlight)?
Does it count explicitly in 'Other Measurements' in about:memory?
Comment 34 Justin Lebar (not reading bugmail) 2012-04-04 06:29:19 PDT
(In reply to Loic from comment #33)
> Nicholas, do you know if there are some memory reporters for the memory use
> of plugin-container.exe (I mean especially about Flash/Java/Silverlight)?
> Does it count explicitly in 'Other Measurements' in about:memory?

We currently do not measure plugin-container.exe at all.
Comment 35 Nicholas Nethercote [:njn] 2012-04-04 06:47:27 PDT
Bug 648415 is open for plugin-container measurement, but no progress has been made on it.
Comment 36 Nicholas Nethercote [:njn] 2013-01-23 14:11:27 PST
FWIW, my "heap-unclassified" is regularly under 10% on my Linux64 box, running a trunk build.  It was 6.4% at the end of the day a couple of days ago.  And it's currently 10.9% on my Mac, which is on FF19 beta.
Comment 37 Phoenix 2013-01-23 15:25:12 PST
Install Stylish and this "issue" would be easily resolved :D
Comment 38 Nicholas Nethercote [:njn] 2013-01-23 17:32:19 PST
> Install Stylish and this "issue" would be easily resolved :D

I don't understand what you mean by 'this "issue"'.  Is heap-unclassified high with Stylish installed?
Comment 39 Phoenix 2013-01-24 01:11:21 PST
(In reply to Nicholas Nethercote [:njn] from comment #38)
> Is heap-unclassified high with Stylish installed?
Right, you'll get something like 16% from beginning and growing to ~30% on usage
Comment 40 Ben Lerner 2013-03-23 20:31:45 PDT
I'm just curious -- I recognize that this meta-bug is mostly tracking heap-unclassified data in Firefox, and that there's a separate meta-bug for B2G.  Is there a comparable bug for Thunderbird?  (On my machine at the moment, heap-unclassified is at 33%, which makes it tricky to help diagnose the memory leak I seem to be seeing...)
Comment 41 Nicholas Nethercote [:njn] 2013-03-23 21:02:28 PDT
> Is there a comparable bug for Thunderbird?

Nope.  You might want to talk to jcranmer, who was working on some Thunderbird memory reporters just the other day.  Alternatively, DMD might help you:  https://wiki.mozilla.org/Performance/MemShrink/DMD
Comment 42 Florian Quèze [:florian] [:flo] (PTO until August 29th) 2013-03-29 04:28:32 PDT
(In reply to Nicholas Nethercote [:njn] from comment #41)
> > Is there a comparable bug for Thunderbird?
> 
> Nope.  You might want to talk to jcranmer, who was working on some
> Thunderbird memory reporters just the other day.  Alternatively, DMD might
> help you:  https://wiki.mozilla.org/Performance/MemShrink/DMD

I tried using DMD on Thunderbird to diagnose bug 844937. All it shows is that Thunderbird desperately needs memory reporters for mailnews/ code, which is the work jcranmer has started in bug 480843.

Note You need to log in before you can comment on or make changes to this bug.