This reverts commit ed098a6dfc.
Revert "Bug 2043789: Use MakeRefPtr to do allocation for various RefPtr variables in xpcom/{io,ioutils}/. r=xpcom-reviewers,emilio"
This reverts commit aa8e617fd8.
Revert "Bug 2043788: Use MakeRefPtr to do allocation for various RefPtr variables in xpcom/{base,ds}/. r=xpcom-reviewers,emilio"
This reverts commit 4f52fb1147.
This is very similar to the previous patch in this series, but now for the
version of this function with "Async" in the name.
Differential Revision: https://phabricator.services.mozilla.com/D299044
The callsites now mostly use MakeAndAddRef (which just stuffs a new object into
a RefPtr and calls `forget()` to yield an already_AddRefed).
In cases where the callsite constructs the object earlier and retains a strong
reference, they'll now use do_AddRef to explicitly generate a strong reference
(as an already_AddRefed) to pass into RegisterStrongMemoryReporter.
Differential Revision: https://phabricator.services.mozilla.com/D299042
This reverts commit 1ab110ab2f.
Revert "Bug 2037761: Change RegisterStrongMemoryReporter to take already_AddRefed instead of a raw pointer, and update callsites. r=dom-core,smaug"
This reverts commit 2e187ddbc8.
This is very similar to the previous patch in this series, but now for the
version of this function with "Async" in the name.
Differential Revision: https://phabricator.services.mozilla.com/D299044
The callsites now mostly use MakeAndAddRef (which just stuffs a new object into
a RefPtr and calls `forget()` to yield an already_AddRefed).
In cases where the callsite constructs the object earlier and retains a strong
reference, they'll now use do_AddRef to explicitly generate a strong reference
(as an already_AddRefed) to pass into RegisterStrongMemoryReporter.
Differential Revision: https://phabricator.services.mozilla.com/D299042
I've occasionally run into this timeout for processes that have a lot of
memory. It'd be nice to be able to up the timeout in those situations.
Differential Revision: https://phabricator.services.mozilla.com/D277037
The maintenance cost of supporting non-profiler builds now outweighs the benefits.
While previously maintained for Tier 3 platforms, the profiler now supports marker recording across these targets.
Removing this toggle simplifies the build system and allows for faster development.
Differential Revision: https://phabricator.services.mozilla.com/D284849
The maintenance cost of supporting non-profiler builds now outweighs the benefits.
While previously maintained for Tier 3 platforms, the profiler now supports marker recording across these targets.
Removing this toggle simplifies the build system and allows for faster development.
Differential Revision: https://phabricator.services.mozilla.com/D284849
I've occasionally run into this timeout for processes that have a lot of
memory. It'd be nice to be able to up the timeout in those situations.
Differential Revision: https://phabricator.services.mozilla.com/D277037
This avoids the small overhead and potential for bugs from the previous
approach of assuming all `const char*` arguments passed to `nsITimer`
initializers are string literals, by instead requiring the argument to be a
`const nsACString&`. This involves changing all callsites to pass a `""_ns`
string literal down instead of a bare string literal.
It appears that while there were currently no buggy callers which
would've provided a dynamic string, there was at least one piece of code
(nsRepeatService::Start) which did pass down a raw char* which may be
dynamically allocated (all callers pass down `nsLiteralCString` so we're
actually OK here right now, but this was a footgun).
Differential Revision: https://phabricator.services.mozilla.com/D261032
This reverts commit 8c929cc018.
Revert "Bug 1979013 - Part 2: Require nsITimer API callers to provide a nsACString, r=xpcom-reviewers,media-playback-reviewers,webrtc-reviewers,profiler-reviewers,dom-storage-reviewers,toolkit-telemetry-reviewers,firefox-style-system-reviewers,mstange,emz,bwc,janv,emilio,padenot"
This reverts commit e01c0a6a32.
Revert "Bug 1979013 - Part 1: Eagerly fetch name for timer callbacks, r=xpcom-reviewers,mccr8"
This reverts commit 9f8e73c163.
This avoids the small overhead and potential for bugs from the previous
approach of assuming all `const char*` arguments passed to `nsITimer`
initializers are string literals, by instead requiring the argument to be a
`const nsACString&`. This involves changing all callsites to pass a `""_ns`
string literal down instead of a bare string literal.
It appears that while there were currently no buggy callers which
would've provided a dynamic string, there was at least one piece of code
(nsRepeatService::Start) which did pass down a raw char* which may be
dynamically allocated (all callers pass down `nsLiteralCString` so we're
actually OK here right now, but this was a footgun).
Differential Revision: https://phabricator.services.mozilla.com/D261032
This is most likely only paranoia, but we did not audit all listeners of "memory-pressure" if they do not dispatch other runnables to the main thread that might change the order.
Differential Revision: https://phabricator.services.mozilla.com/D232087
StrongReportersTable and WeakReportersTable are hash maps keyed on the reporters pointer, thus its location in memory, which results in a hardly foreseeable execution order when iterating over those tables.
Even more, tweaking jemalloc (as we do in bug 1903758) can easily influence the position of newly allocated objects and thus change the execution order.
To make at least the basic reporters defined by nsMemoryReporterManager itself execute in a deterministic order, we introduce an additional array that holds only the (strong) reporters added in Init().
Those reporters are kept alive until the manager lives and are supposed to be sync when dispatched.
Differential Revision: https://phabricator.services.mozilla.com/D230805
StrongReportersTable and WeakReportersTable are hash maps keyed on the reporters pointer, thus its location in memory, which results in a hardly foreseeable execution order when iterating over those tables.
Even more, tweaking jemalloc (as we do in bug 1903758) can easily influence the position of newly allocated objects and thus change the execution order.
This patch makes it so that the execution order is deterministic and starts from the most sensible reporters based on the order with which they are registered in nsMemoryReporterManager::Init.
The easiest way to achieve this is to keep the order with which they are added using an array (the operations are believed to not be time critical).
Differential Revision: https://phabricator.services.mozilla.com/D230358
This fixes the issue described in comment 7 by doing a few changes to how threads are created, and members on nsThreadManager are managed.
* The thread list is moved to be a member of `nsThreadManager`, which is
already a statically allocated singleton.
* The flag for whether new thread creation is allowed is moved from being an
atomic to being guarded by the same mutex as the thread list, meaning that
it could be checked and a new thread could be added to the list atomically.
* Threads which require shutdown are initialized atomically from the point of
view of the thread manager, meaning that the check in ShutdownNonMainThreads
is guaranteed to catch all successfully started nsThread instances.
Differential Revision: https://phabricator.services.mozilla.com/D188623
This fixes the issue described in comment 7 by doing a few changes to how threads are created, and members on nsThreadManager are managed.
* The thread list is moved to be a member of `nsThreadManager`, which is
already a statically allocated singleton.
* The flag for whether new thread creation is allowed is moved from being an
atomic to being guarded by the same mutex as the thread list, meaning that
it could be checked and a new thread could be added to the list atomically.
* Threads which require shutdown are initialized atomically from the point of
view of the thread manager, meaning that the check in ShutdownNonMainThreads
is guaranteed to catch all successfully started nsThread instances.
Differential Revision: https://phabricator.services.mozilla.com/D188623
Daniel Holbert