Jemalloc 4 purges dirty pages regularly during free() when the ratio of dirty
pages compared to active pages is higher than 1 << lg_dirty_mult. We set
lg_dirty_mult in jemalloc_config to limit RSS usage, but it also has an impact
on performance.
So instead of enforcing a high ratio to force more pages being purged, we keep
jemalloc's default ratio of 8, and force a regular purge of all dirty pages,
after cycle collection.
Keeping jemalloc's default ratio avoids cycle-collection-triggered purge to
have to go through really all dirty pages when there are a lot, in which case
the normal jemalloc purge during free() will already have kicked in. It also
takes care of everything that doesn't run the cycle collector still having
a level of purge, like plugins in the plugin-container.
At the same time, since jemalloc_purge_freed_pages does nothing with jemalloc 4,
repurpose the MEMORY_FREE_PURGED_PAGES_MS telemetry probe to track the time
spent in this cycle-collector-triggered purge.
Per the product discussion, the Notification API should be disabled in
ServiceWorker in release builds for 42 since the UX isn't great [1].
The aim is to release in 44.
Apologies for the code duplication for pref checking in Notification and
ServiceWorkerRegistration. There isn't a easy way to get
ServiceWorkerRegistration's generated binding to include Notification.h without
having an attribute/method that uses Notification.
[1]: https://mana.mozilla.org/wiki/x/TgAJAw
The semantics of the new attributes are as follows:
* nightlyAndroid only takes effect on Android.
* If both nightlyAndroid and android are specified, nightlyAndroid takes
* precedence.
These two rules allow us to check for the current situation.
The particular warning here was complaining about an unsafe comparison between
a uint32_t and a bool.
Also, remove ALLOW_COMPILER_WARNINGS=True for this directory.
Get rid of having users dispatch control runnables. It was error prone and
required too much reasoning. It was also possible to end up in a state where
callers would dispatch a WorkerRunnable, which would succeed, so they would not
dispatch a WorkerControlRunnable. Then the worker would stop Running,
canceling and releasing the runnable leading to releasing the proxy in an
unclean state. Instead, we AddRef() and add the feature and remove the feature
and Release() on Notify(). If callers successfully run a WorkerRunnable they
clean the proxy. If not, the proxy stays alive until the worker switches to
Canceling state.
