This is a large number of largely mechanical changes. When possible, the code
was called to directly call `.get()` instead, performing the assertions
manually. In many places PromiseFlatCString() calls were added to dynamically
copy the strings into null terminated buffers if the string was not null
terminated.
Differential Revision: https://phabricator.services.mozilla.com/D286158
The PrioritizableRunnable asserted that it runs on the main thread.
In order to prioritize events on the socket thread we also allow these
runnables to be dispatched to the socket thread.
Differential Revision: https://phabricator.services.mozilla.com/D280953
The PrioritizableRunnable asserted that it runs on the main thread.
In order to prioritize events on the socket thread we also allow these
runnables to be dispatched to the socket thread.
Differential Revision: https://phabricator.services.mozilla.com/D280953
Introduces SUPPORTS_SHUTDOWN_TASKS and SUPPORTS_SHUTDOWN_TASK_DISPATCH flags.
This just wires the function through all event targets without ever being used.
Differential Revision: https://phabricator.services.mozilla.com/D272150
It is replaced by a standard-conforming cast to (void) which is
understood the same by the compiler.
In some cases this could be replaced by `[[maybe_unused]]` but for
expression whose value is ignored, this requires storing to a temporary
variable first, so not going that way.
One notable change is that marking an object of type already_AddRefed as
unused used to implicitly leak memory. This is now made explicit.
Most of the heavy lifting was done through:
$ git grep -l '\<Unused\> <<' | xargs sed -i -e 's/Unused << /(void)/g'
$ git grep -l mozilla/Unused.h | xargs sed -i -e '/mozilla\/Unused.h/ d'
Differential Revision: https://phabricator.services.mozilla.com/D268706
It is replaced by a standard-conforming cast to (void) which is
understood the same by the compiler.
In some cases this could be replaced by `[[maybe_unused]]` but for
expression whose value is ignored, this requires storing to a temporary
variable first, so not going that way.
One notable change is that marking an object of type already_AddRefed as
unused used to implicitly leak memory. This is now made explicit.
Most of the heavy lifting was done through:
$ git grep -l '\<Unused\> <<' | xargs sed -i -e 's/Unused << /(void)/g'
$ git grep -l mozilla/Unused.h | xargs sed -i -e '/mozilla\/Unused.h/ d'
Differential Revision: https://phabricator.services.mozilla.com/D268706
It is replaced by a standard-conforming cast to (void) which is
understood the same by the compiler.
In some cases this could be replaced by `[[maybe_unused]]` but for
expression whose value is ignored, this requires storing to a temporary
variable first, so not going that way.
One notable change is that marking an object of type already_AddRefed as
unused used to implicitly leak memory. This is now made explicit.
Most of the heavy lifting was done through:
$ git grep -l '\<Unused\> <<' | xargs sed -i -e 's/Unused << /(void)/g'
$ git grep -l mozilla/Unused.h | xargs sed -i -e '/mozilla\/Unused.h/ d'
Differential Revision: https://phabricator.services.mozilla.com/D268706
It is replaced by a standard-conforming cast to (void) which is
understood the same by the compiler.
In some cases this could be replaced by `[[maybe_unused]]` but for
expression whose value is ignored, this requires storing to a temporary
variable first, so not going that way.
One notable change is that marking an object of type already_AddRefed as
unused used to implicitly leak memory. This is now made explicit.
Most of the heavy lifting was done through:
$ git grep -l '\<Unused\> <<' | xargs sed -i -e 's/Unused << /(void)/g'
$ git grep -l mozilla/Unused.h | xargs sed -i -e '/mozilla\/Unused.h/ d'
Differential Revision: https://phabricator.services.mozilla.com/D268706
This changes a lot of places, but it's essentially just find and
replace. We had to change this old marker API, because the new API
uses this one to serialize the marker schema fields.
This patch removes the AddKey{Label,}FormatSearchable methods and
switches to use the original AddKey{Label,}Format methods with an
optional parameter instead to make sure that we can pass multiple flags
instead of just Searchable.
For Rust, since we can't have default argument values, we had to create
a new method for them.
Differential Revision: https://phabricator.services.mozilla.com/D260465
We can defer the purging of arenas to happen during idle processing on the main thread.
We already have the following prerequisites thanks to bug 1488780:
- The (often) expensive OS functions to give back memory pages are not blocking the use of the arena on other threads anymore.
- A single call to moz_may_purge_one_now (D232083) wraps just arena_t::Purge() that will just do "some work on one chunk" and tell if more is needed, giving us a fine grained control.
Synchronous purging can block the caller of a memory freeing function for an unexpectedly long time. Furthermore, memory that might be reclaimed very soon can be madvised early and thus its reuse can lead to frequent page faults.
We thus use moz_enable_deferred_purge (see D232083) to queue purge requests and execute them on the main thread only if it is about to become idle. We do this using an IdleTaskRunner that ensures we won't purge too often or never.
We believe that the main thread being idle is probably the best easy indicator we have to tell if the process is idle enough to purge without performance regrets.
We expect the peak memory usage of a single arena to not be affected significantly by this during normal use, but the time that this peak holds up might extend. This means the peak sum of all memory from all running processes may rise for short periods of time until enough purges happened on potentially several processes.
There is a chance to mitigate this effect by lowering the settings of allowed dirty pages for arenas, as there should be less churn in general with this patch, potentially resulting in a lower memory usage in average.
Differential Revision: https://phabricator.services.mozilla.com/D220616
This currently requires exceptions due to bug 1928770 and bug 1928772, which
are done using hard-coded allowed lock names. In addition, reentrant monitors
and recursive mutexes are allowed, as they don't lead to a direct deadlock, and
flag locks such as ChannelEventQueue::mRunningMutex.
Differential Revision: https://phabricator.services.mozilla.com/D227762
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 patch instead replaces this manual reference counting by replacing the raw
pointer in the `ThreadInitData` type with a `RefPtr`.
Differential Revision: https://phabricator.services.mozilla.com/D188622
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 patch instead replaces this manual reference counting by replacing the raw
pointer in the `ThreadInitData` type with a `RefPtr`.
Differential Revision: https://phabricator.services.mozilla.com/D188622
This will be used to deprioritize whole thread pools. The concept works as such:
- Set a thread pool's priority at any time
- Each thread will ensure their priority mirrors the parent pool's priority when it is finished processing events.
I chose to have threads only set themselves to the background when they finish processing events because an event dispatched at an expected priority should be completed at said priority. This ensures that any event dispatch that may expect normal priority (i.e. not operating in the background) has a chance to run at the established priority.
This patch enrolls the background IO to low priority on its creation. It also includes the MacOS implementation of the thread priorities, which utilizes mac's QoS service. According to MacOS's QoS structure, main threads operate at `user-interactive` and offthread work is done at a `default` state, meaning that the OS decides how to set the thread's priority somewhere between `utility` and `user-interactive`. When a thread is put in the background, it must be manually raised back to the expected priority, which means most threads must set themselves to `default` again and the main thread must set itself to `user-interactive`. I demonstrated this in the `nsThread` implementation by checking for the main thread and if this task is running on the main thread somehow, then we use the correct setting.
Rather than having the thread pools dispatch their own deprioritization tasks, I've decided to make this the job of the nsThread. In following bugs we will put entire processes' nsThreads in the background, which will require more use of the new nsThread codepaths.
This behavior is currently restricted to nightly only. On platforms with no implementation, nothing will change.
Differential Revision: https://phabricator.services.mozilla.com/D146534
We aren't likely to try to make these changes any time soon, so cleaning out
these unnecessary methods which just return `this` will simplify things.
I was unable to find any calls to the `.eventTarget` getter in JS, which makes
sense, as the nsIThread type is only really used in JS as a wrapper around the
main thread in older code. Because of that, it has been removed as well.
Differential Revision: https://phabricator.services.mozilla.com/D166605
We aren't likely to try to make these changes any time soon, so cleaning out
these unnecessary methods which just return `this` will simplify things.
I was unable to find any calls to the `.eventTarget` getter in JS, which makes
sense, as the nsIThread type is only really used in JS as a wrapper around the
main thread in older code. Because of that, it has been removed as well.
Differential Revision: https://phabricator.services.mozilla.com/D166605
velzie