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.
It is the only distinguished amount in nsIMemoryReporterManager that isn't
being tested.
--HG--
extra : rebase_source : a9ba01010a464c6a17e7205212e813c6db4a3d5c
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.)
--HG--
extra : rebase_source : 4d1da88d17481916cda5018b7a8298e67c916274
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.
--HG--
extra : rebase_source : f6bad57203ce8a7173f876d578413c4f2cb3cc22
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 patch also adds DMDAnalyzeReports() as a synonym for DMDReportAndDump(),
and deprecates the latter.
--HG--
extra : rebase_source : 651246aa7a0a301f804c124f25beb0e8ed6cd67f
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.
--HG--
extra : rebase_source : 0cfdf2697d10532e5b03cd27fbaadb41f42b837c
extra : amend_source : 0119d4e4881217f105e0e4ba1dfa9c8f7295f3e9
extra : histedit_source : eb49e62c67af2005fdc08d9c9a07f56bee98d558%2C50951e960e450f9b0e48fc7e8ec369d8666a63b0
Every directory with a jar.mn now has JAR_MANIFESTS defined in its
moz.build file.
We also removed the may_skip special consideration of jar.mn files
because this information is now available during tier traversal by the
reader courtesy of the variables being present in moz.build files.
--HG--
extra : rebase_source : 21049b15e6bd9cf65b0805ccaccc4ba5aae93c98
extra : amend_source : 0b1ea866d725beef92d37c6f6d475369ac002e19
