Hi everybody,
Yesterday evening bug 1488554 [1] merged to mozilla-central, thus
enabling the launcher process by default on Windows Nightly builds. This
change is at the build config level.
What is the launcher process?
=============================
Simply put, on Windows builds, the launcher process is an initial
process hosted by firefox.exe that is responsible for configuring and
starting the "real" browser process. Such configurations include early
initialization of the DLL blocklist, as well as the setting of other
Windows process mitigations.
How does this affect startup perf?
==================================
A new test has been added to the xperf-e10s suite in Talos to track
regressions in total elapsed startup time of both the launcher and
browser processes. Previous tests on try have shown the perf impact to
be less than 1%, but that is on a small data set, hence the interest in
gathering more data from Nightly.
On Windows 10 devices with magnetic hard disks, users may actually see a
performance *improvement* due to an altered search path for DLL loading
that results in reduced HDD seeking.
As a developer, how does this affect me?
========================================
If you are not running Windows, you are unaffected! \o/
If you are running Windows, there are two possible issues:
1. Automation
-------------
If you are doing some kind of automation that waits for the Firefox
process to finish, you'll find that the initial Firefox process exits
sooner than the browser, appearing to your script that Firefox is
already done when in fact it is still running. This is because, by
default, the launcher process only lives long enough to stand up the
browser process and transfer foreground to the new browser's window.
In order to make the launcher wait for the browser to complete, pass the
--wait-for-browser flag on the command line. The launcher will wait for
the entire life of the browser process, and will also propagate the
browser process's exit code as its own. The launcher also accepts the
presence of the MOZ_AUTOMATION environment variable as an implicit
--wait-for-browser request.
I have already fixed up our automation to supply this parameter when
necessary, so I expect everything in Mozilla's CI system to already Just
Work.
|mach run| and |mach gtest| also automagically add --wait-for-browser
when necessary.
mozregression updates are being tracked by bug 1494398 [2].
2. Debugging the browser process
--------------------------------
If you launch Firefox via a debugger, the initial process will now be
the launcher process instead of the browser process. To debug the
browser process, here are your options:
* You can attach your debugger to the browser process once it has
started. Obviously this solution is less than ideal if you want to debug
something during startup;
* If you use WinDbg, you may start your debugging session from the
command line with the "-o" option to ensure that the debugger attaches
to all child processes. If you prefer opening your executable via the
GUI, you may select the "Debug child processes also" checkbox within the
"Open Executable" file picker.
* If you use Visual Studio, you may install the Child Process Debugging
Power Tool [3] which, once configured, will make the VS debugger
automagically attach to the launcher's child processes.
How to Help
===========
If you encounter any bugs, please file them blocking bug 1481546 [4] and
needinfo me. As always, feel free to reach out to me if you have any
questions/concerns/comments.
Thanks,
Aaron
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1488554
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1494398
[3]
https://blogs.msdn.microsoft.com/devops/2014/11/24/introducing-the-child-process-debugging-power-tool/
[4] https://bugzilla.mozilla.org/show_bug.cgi?id=1481546
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
