We skip running shutdown collection on the main thread, because we're
exiting right after, but the process still continues when we shut down
a worker, so we should always do collections there.
MozReview-Commit-ID: IQZItm1qWXW
--HG--
extra : rebase_source : 4fd89e36db124a524c240e806a885dee3b68979e
Jemalloc 4 purges dirty pages regularly during free() when the ratio of dirty
pages compared to active pages is higher than 1 << lg_dirty_mult. We set
lg_dirty_mult in jemalloc_config to limit RSS usage, but it also has an impact
on performance.
So instead of enforcing a high ratio to force more pages being purged, we keep
jemalloc's default ratio of 8, and force a regular purge of all dirty pages,
after cycle collection.
Keeping jemalloc's default ratio avoids cycle-collection-triggered purge to
have to go through really all dirty pages when there are a lot, in which case
the normal jemalloc purge during free() will already have kicked in. It also
takes care of everything that doesn't run the cycle collector still having
a level of purge, like plugins in the plugin-container.
At the same time, since jemalloc_purge_freed_pages does nothing with jemalloc 4,
repurpose the MEMORY_FREE_PURGED_PAGES_MS telemetry probe to track the time
spent in this cycle-collector-triggered purge.
The bulk of this commit was generated by running:
run-clang-tidy.py \
-checks='-*,llvm-namespace-comment' \
-header-filter=^/.../mozilla-central/.* \
-fix
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.
nsJSEnvironment::CycleCollectNow does work before and after a CC runs. With ICC, nsJSEnv won't
know where in the CC when a CC is about to begin or end, so this patch reorganizes that work
into two separate callback hooks. This requires adding a new struct, CycleCollectorStats, to
hold data nsJSEnv needs between the two calls.
Rather than trying to pass around a pointer to a results structure, this patch just adds
it to the nsCycleCollector struct, and always stores them. The results are passed back
to the end CC callback.
The name "aListener" is not very descriptive, and with the previous patch, it is only
used to pass in a manually-specified listener that was passed in to CycleCollectNow,
so rename things.
