We've seen in the past that bincode::serialize was spending too much time
allocating and deallocating a Vec to return the serialized payload.
Instead now, we are creating a SmallVec with 64 bytes inline storage, which is
enough for most of our markers for today. This way, SmallVec will try to keep
payloads inside the stack, and it will only allocate if it goes above 64 bytes.
Differential Revision: https://phabricator.services.mozilla.com/D240150
WebGPU CTS run: https://treeherder.mozilla.org/jobs?repo=try&revision=02e0b7243aedb87972250504dd6bf64d74ff3f96
I updated the patch with the expectations from that run.
There were some regressions in tier 2:
- `testing/web-platform/mozilla/meta/webgpu/cts/webgpu/shader/execution/expression/call/builtin/textureStore/cts.https.html.ini`
- test path: `webgpu:shader,execution,expression,call,builtin,textureStore:bgra8unorm_swizzle:*`
- with error: "Error: Unexpected validation error occurred: Shader module creation failed: Parsing error"
- see: https://treeherder.mozilla.org/logviewer?job_id=496834446&repo=try&lineNumber=3089
- `testing/web-platform/mozilla/meta/webgpu/cts/webgpu/shader/validation/expression/call/builtin/value_constructor/cts.https.html.ini`
- new failures related to vector/matrix constructors with abstract types
- see: https://treeherder.mozilla.org/logviewer?job_id=496835790&repo=try&lineNumber=2094
There were also a new failures in tier 3 related to abstract types:
- `testing/web-platform/mozilla/meta/webgpu/cts/webgpu/shader/validation/expression/binary/and_or_xor/cts.https.html.ini`
- `testing/web-platform/mozilla/meta/webgpu/cts/webgpu/shader/validation/expression/binary/bitwise_shift/cts.https.html.ini`
- `testing/web-platform/mozilla/meta/webgpu/cts/webgpu/shader/validation/expression/binary/comparison/cts.https.html.ini`
- `testing/web-platform/mozilla/meta/webgpu/cts/webgpu/shader/validation/expression/binary/div_rem/cts.https.html.ini`
Overall, there were lots of new passes related to abstract types and I suspect those new failures were actually false positives previously.
Limit tests at `testing/web-platform/mozilla/meta/webgpu/cts/webgpu/api/validation/capability_checks/limits/` are as noisy as always...
One more try push with all the changes: https://treeherder.mozilla.org/jobs?repo=try&revision=e3b4d3b039ca9e84aa2f4ec0b824c4530f41695d
Differential Revision: https://phabricator.services.mozilla.com/D239942
Filtering non-matching candidates is the biggest
perf bottleneck in the algorithm to create a
text fragment, especially if the user attempts to
create a text fragment for a very common string
on a very large page.
Since the expensive code only does string comparisons,
it can easily be moved to rust and run in parallel
using rayon.
Differential Revision: https://phabricator.services.mozilla.com/D235559
This implements the crash helper service used to move child process crash
report generation out of the main process and into its own process. This is
implemented as a separate executable that is launched on startup by the main
process on the desktop platforms and as a service hosted by a separate process
on Android.
One limitation of the current code is that the crash helper process needs to
be running before we can start setting exception handlers in child processes.
This limitation is due to how Breakpad exception handlers register themselves
with the crash generator and prevents us from lazily starting the helper (or
restarting it on Android).
IPC with the crash helper is implemented using Unix sockets on Linux and macOS
with the former using sequential packets and the latter using stream sockets.
On Windows we use named pipes. In all cases the choice of IPC was dictated both
by the requirement to eventually talk directly to child processes from within
the sandbox, and to external processes in case of Windows as the Windows
Error Reporting exception handler must be able to reach out to the helper from
within a restricted context. These particular requirements are not used yet but
will be as we move more logic out of the main process logic.
Differential Revision: https://phabricator.services.mozilla.com/D231083
This makes `buildid_reader` usable without `nsstring`/`nserror` crates,
as they rely on functions compiled into libxul. What was previously in
`buildid_reader::reader` is now in `buildid_reader` (top-level), and the
previous top-level of `buildid_reader` has been moved to
`buildid_reader_ffi` (in the `ffi` subdirectory).
Differential Revision: https://phabricator.services.mozilla.com/D237941
This makes `buildid_reader` usable without `nsstring`/`nserror` crates,
as they rely on functions compiled into libxul. What was previously in
`buildid_reader::reader` is now in `buildid_reader` (top-level), and the
previous top-level of `buildid_reader` has been moved to
`buildid_reader_ffi` (in the `ffi` subdirectory).
Differential Revision: https://phabricator.services.mozilla.com/D237941
`cc` upstream broke a few things that have been handled by other patches
motivated specifically by this upgrade:
1. `cc::Build` now rejects unknown targets not baked in. This breaks
`swgl`'s usage of the `SWGL` target. We migrated away from this
behavior in D235480.
2. `cc::Build::is_like_msvc`'s underlying logic changed, and now does
not return `true`. This has been worked around in D236305, and will
be removed after this patch in D236650.
3. PGO flag inheritance changed, which required us to explicitly pass
some PTO- and LTO-related flags to keep compiling. This has been
adjusted in D236966.
These are handled, and there should be no concern (finally) in landing
this. 🫡 Woot!
Differential Revision: https://phabricator.services.mozilla.com/D236957
This implements the crash helper service used to move child process crash
report generation out of the main process and into its own process. This is
implemented as a separate executable that is launched on startup by the main
process on the desktop platforms and as a service hosted by a separate process
on Android.
One limitation of the current code is that the crash helper process needs to
be running before we can start setting exception handlers in child processes.
This limitation is due to how Breakpad exception handlers register themselves
with the crash generator and prevents us from lazily starting the helper (or
restarting it on Android).
IPC with the crash helper is implemented using Unix sockets on Linux and macOS
with the former using sequential packets and the latter using stream sockets.
On Windows we use named pipes. In all cases the choice of IPC was dictated both
by the requirement to eventually talk directly to child processes from within
the sandbox, and to external processes in case of Windows as the Windows
Error Reporting exception handler must be able to reach out to the helper from
within a restricted context. These particular requirements are not used yet but
will be as we move more logic out of the main process logic.
Differential Revision: https://phabricator.services.mozilla.com/D231083
This implements the crash helper service used to move child process crash
report generation out of the main process and into its own process. This is
implemented as a separate executable that is launched on startup by the main
process on the desktop platforms and as a service hosted by a separate process
on Android.
One limitation of the current code is that the crash helper process needs to
be running before we can start setting exception handlers in child processes.
This limitation is due to how Breakpad exception handlers register themselves
with the crash generator and prevents us from lazily starting the helper (or
restarting it on Android).
IPC with the crash helper is implemented using Unix sockets on Linux and macOS
with the former using sequential packets and the latter using stream sockets.
On Windows we use named pipes. In all cases the choice of IPC was dictated both
by the requirement to eventually talk directly to child processes from within
the sandbox, and to external processes in case of Windows as the Windows
Error Reporting exception handler must be able to reach out to the helper from
within a restricted context. These particular requirements are not used yet but
will be as we move more logic out of the main process logic.
Differential Revision: https://phabricator.services.mozilla.com/D231083
