Most of this is fixing functions that in some cases return a value but then
can also run to completion without returning anything. ESLint 2 catches this
where previous versions didn't. Unless there was an obvious other choice I just
made these functions return undefined at the end which is effectively what
already happens.
MozReview-Commit-ID: KHYdAkRvhVr
We have some oddities in our jemalloc stats reporting.
- "heap-overhead-ratio" is a strange measurement: overhead / non-overhead,
expressed as a percentage. And it omits "bin_unused", which appears to be an
oversight.
- "heap-committed" also omits "bin_unused".
- There are some minor errors in memory report descriptions.
This patch fixes these and improves the heap reporting. It makes the following
reporting changes:
- "heap-allocated": Duplicated as "heap-committed/allocated". (We keep
"heap-allocated" because that's a special value used in the computation of
"heap-unclassified".)
- "heap-committed/overhead": Added; it's the same as the sum of the
"explicit/heap-overhead/*" values. Together with "heap-committed/allocated"
it shows clearly what fraction of the heap is overhead and what fraction is
useful.
- "heap-committed": Removed; now implicit as the "heap-committed/" node.
- "heap-overhead-ratio":
- Removed from memory reports; now shown as the percentage of the new
"heap-committed/overhead" node.
- Still available as a distinguished amount (because it's useful in
isolation) but renamed to heapOverheadFraction, and the telemetry ID is
renamed as MEMORY_HEAP_OVERHEAD_FRACTION.
- "heap-chunks": Removed; it's not that interesting, and can be manually
computed as "heap-mapped" / "heap-chunksize" if necessary.
Now that the faster make backend is enabled by default avoiding
cross-jar.mn file conflicts, and now that individual files can't
overlap with wildcards in the same jar.mn files, which were two
main things that the "+" prefix was used for (apart from
cargo-culting), the "+" prefixes in the tree are not necessary
anymore.
|getReportsForThisProcess| differs from |getReports| in that it is limited to current process and is synchronous. When asynchronous memory reporters are added the function will no longer be able tobe synchronous. There isn't much utility in only measuring the current process, so we can remove the function and switch existing users to |getReports|.
The calculation of |explicit| relies on the synchronous |getReportsForThisProcess|, once we have asynchronous reporters this will no longer work. As it is currently referenced in the about::memory tests we can just remove it.
|getReportsForThisProcess| differs from |getReports| in that it is limited to current process and is synchronous. When asynchronous memory reporters are added the function will no longer be able tobe synchronous. There isn't much utility in only measuring the current process, so we can remove the function and switch existing users to |getReports|.
The calculation of |explicit| relies on the synchronous |getReportsForThisProcess|, once we have asynchronous reporters this will no longer work. As it is currently referenced in the about::memory tests we can just remove it.
This changes the way nsMemoryReporterManger handles child processes;
instead of using an observer message and trying to keep a count of child
processes expected to answer, it directly iterates a copy of the list
of content processes and explicitly handles children which exit before
their reports start.
Note that GC/CC logs still run at full concurrency, and that no child
reports start until the parent is finished (see bug 1151597) regardless
of concurrency limit.
This changes the way nsMemoryReporterManger handles child processes;
instead of using an observer message and trying to keep a count of child
processes expected to answer, it directly iterates a copy of the list
of content processes and explicitly handles children which exit before
their reports start.
Note that GC/CC logs still run at full concurrency, and that no child
reports start until the parent is finished (see bug 1151597) regardless
of concurrency limit.
Paths of the form:
'jar:file:///tmp/tmp2DqEYgBuildGetter_firefox/firefox/omni.ja!/components/Webapps.js'
are now normalized to:
'jar:file:///.../omni.ja!/components/Webapps.js'
when diffing about:memory reports. This is particularly useful when checking
for regressions across builds which will often have different install paths.
This changes about:memory so that whenever measurements are shown, the origin
of those measurements is visible in the title bar.
- "about:memory (live measurement)" is used when you do "Measure".
- "about:memory (<filename>)" is used when you do "Load...".
- "about:memory (diff of <filename1> and <filename2>)" is used when you do
"Load and diff...".
- "about:memory" is used in all other cases, e.g. when about:memory is first
loaded, and after all non-measurement actions (GC, GC, etc.)
Now that memory reports are gzipped by default (not to mention *huge* when
unzipped), this button is no longer useful. A "load from URL" button (bug
859603) would be much better, but for now let's just remove the useless
functionality so it doesn't get in the way.
After the patches in this bug, we only inject a newline at block element
boundaries. In order to get these tests to pass, we just compare the
trimmed version of the actual and expected tests.
