We need a sync IPC call for this because otherwise the number of smaller sync messages we would need to call would be variable.
Differential Revision: https://phabricator.services.mozilla.com/D88076
This, hopefully, begins to address an ongoing global problem where we have few, if any, insights into the performance of individual build tasks (compilations, calls into Python scripts, etc.) At most we have aggregated statistics about how long tiers last, combined with `sccache` aggregates across the entire build (which don't cover non-compilation tasks). This has a few implications:
1. It's impossible to identify bottlenecks, except by going out of your way to notice and reproduce them. e.g. no one, to my knowledge, was aware that `make_dafsa.py` was a bottleneck until someone happened to notice and report it in bug 1629337. We could have systems that automatically detect this sort of thing, or at least that make it easier to do so than by CTRL-C'ing in the middle of the build several times to try to reproduce the problem.
2. It's impossible to detect regressions, unless the regression is so pronounced and severe that it has an immediate impact on the overall build time and triggers build time alerts.
3. It's impossible to identify that you have *fixed* regressions, except by doing ad-hoc timing measurements by building individual `make` targets. This is error-prone and annoying.
Here we propose a low-friction system wherein individual build tasks log their build own perf info. For now, that's a write to `stdout` consisting of the string `BUILDTASK ` followed by a simple JSON object with a start time, end time, the `argv` of the task, and an additional `"context"` key (I anticipate this could be used to annotate the task with relevant per-task for later aggregation, for example: was this an `sccache` cache hit or not? For now, it's empty everywhere). The build controller then collects this data, validates it, and writes out the entire list of build tasks as a JSON file after the build has completed, similarly to what we already do with `build_resources.json`. We already parse some `make` output to do stuff like tracking when we switch tiers, so this isn't a huge architectural shift or anything.
In my opinion this "should" happen at the build system, or `make`, level, but `make` doesn't expose anything resembling this information to my knowledge, so this has to be implemented outside of `make`. One could implement something like this at the `sccache` level but that doesn't touch anything but C/C++/Rust compilation tasks; an ideal solution would support other generic build tasks. We could also fork `make` to add this feature ourselves, but for several reasons I don't think that's tractable. :)
Of course, this approach has downsides:
1. We depend on parsing the `stdout` of `make`, and processes can unfortunately sometimes trample on each other, leading to data loss for individual build tasks occasionally. This is a necessary limitation of the model to my knowledge, and I don't know that it can be fixed generally. In my testing, not much data tends to be lost usually.
2. Dumping arbitrary data to `stdout` isn't always possible or desirable. If you're not careful about it this can also result in noisier-than-necessary tasks, especially when those tasks are not invoked by a parent process that knows how to handle the special `BUILDTASK` lines.
3. This data is raw enough where aggregation is not completely trivial.
4. This functionality has to be added for any new kind of build task whose performance we'd like to track; it doesn't come "for free" due to not being able to be implemented at the build system level.
5. The data isn't awfully small due to the `argv`'s (at this point, not nearly big enough where we need to be concerned about it IMO, but maybe that will change in the future?)
One can imagine a couple other architectures that could avoid the first two problems, namely: 1) we could use a "real" database that would not dump info to `stdout` and wouldn't lose data, like `sqlite3`; or, 2) we could set up another server, similar to `sccache`, that collects this data from subprocesses and aggregates it, making sure not to lose any along the way. Both of these have enough overhead, in terms of engineering effort or actual impact on latency, where I dont know that they make any sense to even attempt implementing. The remaining continue to be real issues, however.
After this is landed there are a few ways forward. We can start uploading these files as build artifacts in CI to allow us to reason about performance impacts of changes in `central`. We can easily add this functionality to the `sccache` client to start tracking those builds as well. We already have a very simple visualization of build tier timing in `mach resource-usage`; we could join that data against the `BUILDTASK` data to produce a very clear visualization of build bottlenecks, i.e., "why is the `export` tier taking so long", etc.
Differential Revision: https://phabricator.services.mozilla.com/D80284
This changes most of our automation builds to clang 11.0.0 rc2.
Not included:
* code coverage builds, per bug 1660341
* mingw builds, which have traditionally been on their own update cadence, and in this case are blocked anyway by bug 1658632
This will leave some unused clang-9 task definitions. I intend to clean them up, but at a later date. For now I want to focus on making sure this update sticks, since patches like this have a tendency to bounce.
Differential Revision: https://phabricator.services.mozilla.com/D88313
A few test cases fail under clang-11 on Linux debug builds only. As described in the bug, we unfortunately don't have the bandwidth to investigate, so this patch accepts the failures.
Differential Revision: https://phabricator.services.mozilla.com/D88363
For not-well-understood reasons, ld's `--gc-sections` discards a large number of the PGO bookkeeping structures that enable us to keep track of function counters, and the effect gets worse in object files generated by clang-10.
As much as I'd like to understand this better, the investigations take way too much time. As a path of least resistance, we can disable `--gc-sections` for the instrumentation phase of PGO builds. It won't harm anything since users never see those builds, and it will improve the performance of the optimized phase greatly.
Differential Revision: https://phabricator.services.mozilla.com/D78112
Some geckoview tests require gradient usage. Since background
images are async, these tests would wait for a contentful paint
to make sure the images are decoded before running the assertions.
This causes an issue because gradient-only backgrounds aren't
contentful anymore according to the latest spec.
We fix the tests by adding a transparent gif to the background
image list to trick the contentful detection.
Differential Revision: https://phabricator.services.mozilla.com/D88230
The current tests workflow works as wait for three frames, then
check if the performance entry shows up. This workflow is flaky
because the three frames piece is hardcoded and there are
chances that the paint takes longer than three frames because it
really depends on the current workload of the system.
We fix it by loading the image into memory first, so that it's
decoded before the painting.
Depends on D68647
Differential Revision: https://phabricator.services.mozilla.com/D68888
In this patch, we changed a lot of tests from PRECONDITION_FAILED to
timeout because we added the PerformancePaintTiming API so the
precodition is no longer failed. TIMEOUT is required because
these tests expect two performance paint entries, but we only
support one of them.
Depends on D68645
Differential Revision: https://phabricator.services.mozilla.com/D68646
Some tests made some assumptions about the number of returned entries
by performance.getEntries, and these assumptions are not valid
anymore once we added new entries.
Depends on D66463
Differential Revision: https://phabricator.services.mozilla.com/D68645
This listens to state changes set via SharedData. Those state changes are executed by
front-end code in a later patch in this series.
Depends on D87129
Differential Revision: https://phabricator.services.mozilla.com/D86719
`play` default handler is a special case, we don't want to run it arbitrarily in order to get a better user experience.
If we have an active media session, the play should only be triggered on that session, which is something a user really wants to resume. Therefore, adding some restrictions to call default play handler only when
(1) We don't have an active media session (If we have one, the play action handler should only be triggered on that session)
(2) Active media session without setting action handler for `play`
Differential Revision: https://phabricator.services.mozilla.com/D88107
As we want to have an ability to do different operations on different browsing contexts for those actions with default handlers (play/pause/stop), so in D87142 we have changed `ContentMediaController` per browsing context. Techically it's per inner window, but it means each browsing context would have one corresponding `ContentMediaController` if the web content is in that browsing context.
The approach to achieve the goal is that, when getting those actions, we would notify to the top level browsing context, then go through its children to ensure that each browsing context can be operated correctly. By doing so, we can trigger default action handler and customized action handler on different browsing context.
Eg. A page has a child iframe, which has active media session with an action handler for `pause`. A page and iframe are both playing media. When pressing `pause`, default action handler would be run on main frame, and the customized action handler would be run on iframe.
Differential Revision: https://phabricator.services.mozilla.com/D87143
Before applying this patch, `ContentMediaController` is per process, it might contains `ContentMediaControlKeyReceiver` coming from different browsing context, and we are not able to treat those receivers differently based on the browsing context they exist in.
The goal to change `ContentMediaController` per inner window is to allow us to have an ability to treat receivers in different browsing context with different operations without interering each other.
As the `ContentMediaController` control the media playback in web context, which life cycle is tight to the inner window, that is why I choose to create `ContentMediaController` on the inner window.
In addition, update the comment to make its up-to-date.
Differential Revision: https://phabricator.services.mozilla.com/D87142
We determine which media session is active media session in chrome process, but the media session in content process doesn't know the detail.
This patch would store the active session context Id on the top level WindowContext, so that media session in content process can know if it's an active context or not, which helps to trigger the action handler only on active media session, after changing our propagation mechanism in following patches.
Differential Revision: https://phabricator.services.mozilla.com/D88106
Having the fill logins context menu on PDF forms could lead to users
accidentally entering their login information into to a PDF form which
is probably not a desired or expected behavior.
Differential Revision: https://phabricator.services.mozilla.com/D88198
This stores the slot span in the object slots error for dictionary mode
objects. Since it's possible to have dictionary mode objects without dynamic
slots, this adds sentinel ObjectSlots instances for each possible dictionary
slot span up to the maximum number of fixed slots.
Differential Revision: https://phabricator.services.mozilla.com/D87888
Eitan Isaacson
Ricky Stewart
Emil Farisan
yohaan
Jared Wein
Peter Van der Beken
David Major
Mats Palmgren
Sean Feng
Jeff Gilbert
Mike Conley
Andreas Pehrson
Andrew Osmond
Cosmin Sabou
Sebastian Hengst
Matthew Gaudet
alwu
Iain Ireland
Adam Vandolder
James Willcox
Tom Tung
Marco Bonardo
Brendan Dahl
Bogdan Tara
Jon Coppeard