As mentioned in bug 1747354, the location of the dist directory is
relied to be $topobjdir/dist, so just use that consistently rather
than getting it from a separate variable for rust build scripts.
Differential Revision: https://phabricator.services.mozilla.com/D136556
Previously the process startup timestamp was computed lazily but this caused
some issues with some of our static analysis infra (see bug 1678152). This
moves computing the timestamp early during process startup and makes it happen
unconditionally.
Differential Revision: https://phabricator.services.mozilla.com/D136406
As mentioned in bug 1747354, the location of the dist directory is
relied to be $topobjdir/dist, so just use that consistently rather
than getting it from a separate variable for rust build scripts.
Differential Revision: https://phabricator.services.mozilla.com/D136556
* Define urlbarMarginInline and urlbarSearchButtonWidth as CSS rather than preprocessor variables
* Replace the urlbarViewPadding, urlbarViewFaviconWidth and urlbarViewIconMarginEnd preprocessor variables with CSS vars.
* Remove %ifdefs around the license comment in these 2 files
* Update ambiguous/out-of-date comment in the skeleton UI code
Differential Revision: https://phabricator.services.mozilla.com/D135962
* Define urlbarMarginInline and urlbarSearchButtonWidth as CSS rather than preprocessor variables
* Replace the urlbarViewPadding, urlbarViewFaviconWidth and urlbarViewIconMarginEnd preprocessor variables with CSS vars.
* Remove %ifdefs around the license comment in these 2 files
* Update ambiguous/out-of-date comment in the skeleton UI code
Differential Revision: https://phabricator.services.mozilla.com/D135962
Note: The atomic variable is named `gSkipSampling`, not mentioning forks because it could later be used in other situations, so it's best to describe it by the effect it has.
Differential Revision: https://phabricator.services.mozilla.com/D136205
`PrintUsageThenExit(code)` was supposed to exit when `code` was not zero, but:
- The name didn't reflect that, so it was confusing that `PrintUsageThenExit(0)` would *not* exit.
- The implementation in the Base Profiler exited anyway! This caused issues with some legacy code that still used the now-removed "threads" feature.
This patch renames the function to just `PrintUsage()` and never exits, leaving the caller to invoke `exit(code)` as needed -- with the added benefit that it's possible to exit with a zero code, useful in cases where an exit is not actually an error.
Differential Revision: https://phabricator.services.mozilla.com/D135666
I'm gonna guess there was no existing use of the tuple
serialization/deserialization code, because `Bytes` doesn't exist in the
deserializer, and cannot possibly function properly on tuple members that
serialize to a non-constant size, since it's called on a default-constructed
tuple.
This patch took inspiration in the deserializer for Variant and seems to work
fine.
Differential Revision: https://phabricator.services.mozilla.com/D135028
I'm gonna guess there was no existing use of the tuple
serialization/deserialization code, because `Bytes` doesn't exist in the
deserializer, and cannot possibly function properly on tuple members that
serialize to a non-constant size, since it's called on a default-constructed
tuple.
This patch took inspiration in the deserializer for Variant and seems to work
fine.
Differential Revision: https://phabricator.services.mozilla.com/D135028
While mingw builds don't require user32 and advapi32 explicitly, it doesn't
hurt for them to be there (and they're required for clang-cl build).
Likewise, while clang-builds don't require uuid and userenv explicitly
because they're pulled in via #pragmas in the source code, mingw doesn't
support those #pragmas and needs them explicitly, which doesn't hurt the
clang-cl builds.
Differential Revision: https://phabricator.services.mozilla.com/D134737
While mingw builds don't require user32 and advapi32 explicitly, it doesn't
hurt for them to be there (and they're required for clang-cl build).
Likewise, while clang-builds don't require uuid and userenv explicitly
because they're pulled in via #pragmas in the source code, mingw doesn't
support those #pragmas and needs them explicitly, which doesn't hurt the
clang-cl builds.
Differential Revision: https://phabricator.services.mozilla.com/D134737
This is necessary, because the next patch will remove the "threads" feature, and some tests only add that one feature so now they will have an empty feature list, equivalent to a feature bitset of 0 (zero).
Differential Revision: https://phabricator.services.mozilla.com/D134136
This patch was r+ed before by Ted, but it never landed because I initially intended
to address Ted's review comment (about making it work on 10.11 and below), and
because it needed to be rebased around bug 1374888.
The rebase turned out to be really simple, and Ted's review comment no longer applies
because Firefox no longer runs on 10.11 and below.
Profile with fix: https://share.firefox.dev/3oYzvO6
Differential Revision: https://phabricator.services.mozilla.com/D134008
The main thread is the busiest, so it benefits the most from having its own chunked buffer. This removes one allocation when capturing a marker stack on the main thread of each process.
That buffer is allocated when the first profiler starts, and is destroyed when the last profiler stops.
Note: Further improvements are possible (e.g.: Pool of pre-allocated buffers, attempting to use a stack-based buffer, etc.), but they are more complex and will require more work in future bugs.
Differential Revision: https://phabricator.services.mozilla.com/D133725
The resulting code should be the same. The factored lambda will be called in the next patch with a different chunked buffer.
Differential Revision: https://phabricator.services.mozilla.com/D133724
The main thread is the busiest, so it benefits the most from having its own chunked buffer. This removes one allocation when capturing a marker stack on the main thread of each process.
That buffer is allocated when the first profiler starts, and is destroyed when the last profiler stops.
Note: Further improvements are possible (e.g.: Pool of pre-allocated buffers, attempting to use a stack-based buffer, etc.), but they are more complex and will require more work in future bugs.
Differential Revision: https://phabricator.services.mozilla.com/D133725
The resulting code should be the same. The factored lambda will be called in the next patch with a different chunked buffer.
Differential Revision: https://phabricator.services.mozilla.com/D133724
Historically, va_copy was not supported everywhere (notably, MSVC didn't
have it). That's not true anymore. We already have code such as
xpcom/base/Logging.cpp that uses it unconditionally.
Differential Revision: https://phabricator.services.mozilla.com/D133458
The main thread is the busiest, so it benefits the most from having its own chunked buffer. This removes all but one allocation when capturing a marker stack on the main thread of each process.
Note: Further improvements are possible (e.g.: Pool of pre-allocated buffers, attempting to use a stack-based buffer, etc.), but they are more complex and will require more work in future bugs.
Depends on D133724
Differential Revision: https://phabricator.services.mozilla.com/D133725
The resulting code should be the same. The factored lambda will be called in the next patch with a different chunked buffer.
Depends on D133723
Differential Revision: https://phabricator.services.mozilla.com/D133724
