74920 - new memory logging tool

Status: RESOLVED WONTFIX

(Core :: XPCOM, enhancement, P5)

Description

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

A few weeks ago I got a neat idea for (yet another) leak/bloat tool,
and rather than investigating how to integrate my ideas into
nsTraceMalloc (i.e., adding a post-processing tool for nsTraceMalloc
logfiles), I just went along and (in pockets of spare time over the
course of a week) wrote it.  Whether or not that was a good idea, it's
done (and it was kinda fun to write, and not that hard).

So now I have a new tool lying around in my tree that can log (in
realtime) a tree showing sources of total allocation (in bytes or
allocation counts), sources of leaked allocations (in bytes), and/or
sources of allocation for the memory allocated at the time of maximum
memory usage (in bytes).  At least that's what I think it does... I
haven't had much chance to test it yet.  I also added a few new
features to nsVoidArray in order to do this.

And, since it's written, I shouldn't just keep it all to myself, so
diffs coming up, right here.

Comment 1

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: diffs for new tool

Comment 2

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

To use:  set one of the following environment variables to "1", "2", or a
filename just as for the nsTraceRefcnt tools:

 * XPCOM_BL_LEAK_LOG - log for allocations that leaked (in bytes)
 * XPCOM_BL_ALLOC_LOG - log for total allocations (in allocation counts)
 * XPCOM_BL_BLOAT_LOG - log for total allocations (in bytes)
 * XPCOM_BL_MAX_LOG - log for active allocations at point of maximum memory
usage (in bytes)

Comment 3

[Chris Waterson]

r=waterson on the nsVoidArray.[h|cpp] and nsQuickSort.h change.

Comment 4

[Randell Jesup [:jesup] (needinfo me)]

Bug 90545 subsumes the nsVoidArray change.  (The Sort stuff was already in; I
added MoveElement on my own, then found an almost identical implementation
here).

Comment 5

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

We don't really need this, although it might be neat to add another trace-malloc
reader that does something similar.  That would require modifying trace-malloc
according to some of my earlier (more extensive) patches in bug 84831, since it
would require matching allocations and frees.

Comment 6

[Andrew McCreight [:mccr8]]

It sounds like this has been superseded by a number of other tools (ref count logging, cachegrind, etc.) in the decade since it was filed.

Comment 7

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Those tools aren't particularly relevant; however, diffbloatdump.pl does what this tool did.