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.
The -*- file variable lines -*- establish per-file settings that Emacs will
pick up. This patch makes the following changes to those lines (and touches
nothing else):
- Never set the buffer's mode.
Years ago, Emacs did not have a good JavaScript mode, so it made sense
to use Java or C++ mode in .js files. However, Emacs has had js-mode for
years now; it's perfectly serviceable, and is available and enabled by
default in all major Emacs packagings.
Selecting a mode in the -*- file variable line -*- is almost always the
wrong thing to do anyway. It overrides Emacs's default choice, which is
(now) reasonable; and even worse, it overrides settings the user might
have made in their '.emacs' file for that file extension. It's only
useful when there's something specific about that particular file that
makes a particular mode appropriate.
- Correctly propagate settings that establish the correct indentation
level for this file: c-basic-offset and js2-basic-offset should be
js-indent-level. Whatever value they're given should be preserved;
different parts of our tree use different indentation styles.
- We don't use tabs in Mozilla JS code. Always set indent-tabs-mode: nil.
Remove tab-width: settings, at least in files that don't contain tab
characters.
- Remove js2-mode settings that belong in the user's .emacs file, like
js2-skip-preprocessor-directives.
This has a few semi-interdependent pieces:
* Factoring out the file opening/closing/renaming from the GC/CC logging.
* Using IPC to have the child log to files that the parent opened.
* Changing nsIMemoryInfoDumper.dumpGCAndCCLogsToFile to report completion
of child process logging (which was impossible before this, and which is
needed to have a meaningful test case).
* Changing about:memory to dump logs for child processes, matching the
behavior of the "Measure" button, because it can tell the user where
they are now.
* Add a test for multiprocess GC/CC log dumping (only of the XPCOM
interface, not by clicking buttons and scraping the about:memory page,
but done as a chrome mochitest to start remote browsers); based on
test_memoryReporters2.xul in the same directory.
Many moz.build files define things that could be defined in parent
moz.build files. Keeping the number of moz.build files low helps with
build times due to less I/O and fewer directories traversed.
This patch eliminates a lot of moz.build files by moving their content
into parent moz.build files.
