Fairly straightforward, just a blanket removal. Haven't heard
anything on dev-platform or fx-data-dev regarding this removal,
so I think it's likely safe to remove on Nightly, and we can
revert if anyone makes a fuss.
As part of removing the HangMonitor, I renamed a few things and
reorganized the namespaces to not depend on a HangMonitor
namespace. Hopefully this doesn't produce too much noise in the
diff, it just seemed appropriate to move everything around
rather than keep dangling vestiges of the old system.
MozReview-Commit-ID: 8C8NFnOP5GU
--HG--
extra : rebase_source : 59e4a6ced7d14d2a01c0b79e944078ea84cae523
Same approach as the other bug, mostly replacing automatically by removing
'using mozilla::Forward;' and then:
s/mozilla::Forward/std::forward/
s/Forward</std::forward</
The only file that required manual fixup was TestTreeTraversal.cpp, which had
a class called TestNodeForward with template parameters :)
MozReview-Commit-ID: A88qFG5AccP
This was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
Fairly straightforward, just a blanket removal. Haven't heard
anything on dev-platform or fx-data-dev regarding this removal,
so I think it's likely safe to remove on Nightly, and we can
revert if anyone makes a fuss.
As part of removing the HangMonitor, I renamed a few things and
reorganized the namespaces to not depend on a HangMonitor
namespace. Hopefully this doesn't produce too much noise in the
diff, it just seemed appropriate to move everything around
rather than keep dangling vestiges of the old system.
MozReview-Commit-ID: 8C8NFnOP5GU
--HG--
extra : rebase_source : a8840bd26f4b01b756ffa72345ababb625048550
Whatever compiler bugs required this destructor to be public have
either long since been fixed, or the compilers themselves have become
obsolete. Plus we get to fix a wrong comment and make another class
final in the process.
When memory-pressure events were first used in an e10s environment it was
to implement memory minimization from about:memory. However when low memory
detection was first introduced in Firefox OS an issue arised with this scheme:
every process was using a kernel-based low-latency mechanism to detect low
memory scenarios and send memory-pressure events; but the main process events
were also being forwarded to all child processes causing listeners to be
triggered twice. Because of this -no-forward events were introduced and used.
Currently however low-memory is detected via polling, so there will always be
a significant delay between the beginning of the low-memory scenario and its
detection. Because of this there is no value in having content processes poll
on their own and it's best to have only the main process do it and then
forward the memory-pressure events to all child processes.
MozReview-Commit-ID: AMQOsEgECme
--HG--
extra : rebase_source : 1b408b31dd27940981407f50f2e5f07e354b16d7
The JS engine has changed the APIs that cooperative scheduling relies
on into immediate crashes. Some users seem to set the prefs, and then
we get a lot of crashes on Nightly. This removes the top-level pref to
save them some grief.
I continue to pass the pref as false to the child process to avoid
weirdness if we somehow we get this far when the parent and child have
different versions.
MozReview-Commit-ID: 3o3yV2efx2r
--HG--
extra : rebase_source : 398c4d77ce3f78f3814ac97882b4a5e3190c44f7
For Fennec on Android, if we haven't received memory pressure notifications from
the OS for a certain amount of time (in the order of ~15 mins), we assume that
we're no longer under memory pressure. In order to turn the bfcache back on when
that happens, we now want to be able to forward this fact to Gecko as well.
Unfortunately, the way memory pressure is tracked using an atomic variable
doesn't easily allow to fully extend the existing priority rules between "new"
and "ongoing" to include a new "stopping of memory pressure" event. Since we're
not using Dispatch*Eventual*MemoryPressure on Android and therefore the queuing
priority behaviour isn't actually relevant for us, we just ignore that and only
enforce that a pending "new" memory pressure event takes priority over a "stop"
event.
MozReview-Commit-ID: 90C9KogUyvf
--HG--
extra : rebase_source : 4e71a31433557d8d486f941953717a88d5d87e7d
PerformanceCounters are currently disabled in two ways:
- a preference that's off by default "dom.performance.enable_scheduler_timing"
- calls made only for nightly using #ifndef RELEASE_OR_BETA
In order to simplify the code, let's remove the #ifndef and rely only on the pref.
That will also allows us to use the feature in every version going forward.
The performance will not be impacted since the current code is already using
the (cached) pref value to determine if the counters are used.
MozReview-Commit-ID: 47t2M1O13aH
--HG--
extra : rebase_source : e129e1829f1dc37c019e50e156474c4876d6d6cb
Otherwise, one can do thinkos like:
MakeScopeExit(...);
and the scope exiting function will execute much earlier than the
intended:
auto guard = MakeScopeExit(...);
Chromeutils.RequestPerformanceMetrics() is now composed of two parts:
- calls content processes via IPDL to get their counters
- directly dispatch counters from the parent process
MozReview-Commit-ID: HlgcEOzkyAq
--HG--
extra : rebase_source : 60e81a27cd3a1bf1378e6b977529964507633b63
We only use nsINamed on runnables for certain kinds of telemetry, and
those kinds of telemetry aren't being gathered on RELEASE_OR_BETA
builds. We effectively make nsINamed::GetName a no-op when we're not
collecting said telemetry. But implementing nsINamed does have a cost:
the vtable of every runnable (and we have hundreds of subclasses of
mozilla::Runnable) will contain pointers for GetName (and extra pointers
for QueryInterface/AddRef/Release), and all those pointers times all
those subclasses adds up quickly. Let's not implement nsINamed when
nsINamed isn't going to be used.
This change saves ~100K of binary size on x86-64 Linux; the savings
should be similar on other 64-bit systems, and ~50K on 32-bit systems.
We risk a shutdown hang without any clues if a dangling reference somewhere
keeps a SharedThreadPool alive past xpcom-shutdown-threads. This because
xpcom-shutdown-threads waits for all SharedThreadPool to be destroyed before
advancing shutdown further. nsCycleCollector::Shutdown comes after
xpcom-shutdown-threads so it is possible that a reference-cycle unexpectedly
keeps a SharedThreadPool alive and blocks shutdown indefinitely.
This patch attempts to help diagnose future cases like this by printing which
SharedThreadPools we are going to wait for to stderr.
MozReview-Commit-ID: CwTApYUMikA
--HG--
extra : rebase_source : f29d04508cf492c82d65f324d7b1990849a0da13
Adds a PeformanceCounter class that is used in DocGroup and WorkerPrivate
to track runnables execution and dispatch counts.
MozReview-Commit-ID: 51DLj6ORD2O
--HG--
extra : rebase_source : b481c9aa3b735569722bb7472872ec2d22adcb89
A lot of our thread pools use the default stack size for the platform
they're on, which can be rather large (8MB, usually, on Linux and OS X)
and is probably too much for the typical thread in the thread pool
regardless. SharedThreadPool already has some logic for selecting a
reasonable stack size for worker threads; let's move that logic to
nsIThreadManager so that logic (and constant) can be shared more
broadly. (That we already have a couple of instances of
SharedThreadPool usage solely for this constant suggests that it is a
concept that should be available in a more central location.)
Otherwise, we might enter JS, decide to GC, and deadlock because we were
trying to dispatch tasks to the main thread's event queue while holding
the lock for the event queue.
This enables having a const nsMainThreadPtrHandle<T> member which we want to
ensure doesn't get assigned to, but whose (the `T`'s) non-const methods are
still usable on main thread. Similar to how RefPtr<T> works.
MozReview-Commit-ID: 8CG0MwIZmLc
--HG--
extra : rebase_source : f0e897d3bf4f9a4d752e964ef63de73a9e710752
Currently nsIThreadManager::spinEventLoopUntil doesn't monitor the shutting
down. Firefox shutting down can be blocked by a 'broken' use of
nsIThreadManager::spinEventLoopUntil.
nsIThreadManager::spinEventLoopUntilOrShutdown should be used instead.
It was decided in bug 1430669 that we won't enable gcc's -Wsuggest-override warnings at this time, so these ugly pragmas from bug 1428535 won't be necessary.
--HG--
extra : rebase_source : 221b1f40bb071933ad3e320ce2fa491b2a5917fb
extra : amend_source : 7fc3e6ff067aa5ae8d728e1751de3d2590d31493
The NS_IMPL_NAMED_* macros rely on the mName field, which are not
defined on beta or release, so don't use them on those branches, so
that Firefox will build.
MozReview-Commit-ID: 9wEnPqshBJ8
--HG--
extra : rebase_source : 1ee201c1f0049b02fb57679908915920226592a2
Most subclasses of Runnable don't bother to override AddRef and
Release, so XPCOM leak checking ends up reporting Runnable, which
makes it impossible to know what is actually leaking.
Each subclass of Runnable is already required to pass in the name of
the class, which is stored in the field mName. This patch changes
Runnable to use mName as the class name for XPCOM leak checking, thus
giving each subclass a specific name without needing to change the
hundreds of existing subclasses of Runnable.
The limitation of this approach is the classes that DO use
NS_IMPL_ADDREF/RELEASE_INHERITED end up using the same class name that
is used by the superclass AddRef/Release, but with a different size,
which causes assertions in the leak checker. To work around this, I
change NS_IMPL_ADDREF/RELEASE_INHERITED to not call into
NS_LOG_ADDREF/RELEASE for classes that are a subclass of
Runnable. This needs to use IsConvertible<> and not IsBaseOf<> because
the latter requires the classes involved to be defined, and headers
can use nsISupportsImpl.h without nsThreadUtils.h.
MozReview-Commit-ID: H0pgvwQSZAE
--HG--
extra : rebase_source : 0be13fe2e649e62be1f9471fc03fac43024eb0aa
Make unlabeled runnables be the runnables we tag with extra
information, since they're the ones we want to decrease.
Note: This changes values gathered for telemetry!
If any of the promises gets resolved/rejected prior MozPromise::All completing, it would return nullptr
MozReview-Commit-ID: Lqhv2t2upvF
--HG--
extra : rebase_source : 0c85172958c00a2ac3aa0bd33e4e50dd1893c3ba
This removes an unnecessary level of indirection by replacing all
nsStringGlue.h instances with just nsString.h.
--HG--
extra : rebase_source : 340989240af4018f3ebfd92826ae11b0cb46d019
There's no good reason why these can't be code constants.
Especially given that, due to a bug, changes to the
"idle_queue.{min,long}_period" constants were not being passed onto the C++
code!
Here's why: those two prefs were specified as integers in all.js. But we used
AddFloatVarCache() to set up the reading of those prefs. libpref fakes floats
by storing them as strings and then converting them to floats when they are
read.
Which means that AddFloatVarCache() used to fail to get the value from all.js
-- because there's a type mismatch, int vs. string -- and instead use the
fallback default. That value is the same as the one in all.js, which is lucky.
But if someone changed the value in about:config to 100 (an integer), a similar
failure would have occured and the value used by the C++ code wouldn't be
updated!
Also note that idle_queue.max_timer_thread_bound did not have a value in
all.js.
What a mess!
--HG--
extra : rebase_source : 86f8fa905163803eb95007609c029e18c2c4f586
We can save the entry in the hashtable, and then re-use that entry as a
starting point for removing from the hashtable, should that become
necessary. This saves us having to rehash things, at a minimum.
Defining Get() in the declaration of InputEventStatistics implicitly
sticks an "inline" on the function, which is not what we want: inlining
it spreads around a lot of static initialization code. Providing an
out-of-line definition is much better in terms of code size.
We were extracting elements from the queue and unnecessarily refcounting
them, rather than transferring the owning reference out of the queue and
out to the caller.
This lets us replace moz_xstrdup() of string literals with AssignLiteral(),
among other improvements.
--HG--
extra : rebase_source : 9994d8ccb4f196cf63564b0dac2ae6c4370defb4
This also fixes the Unix part of bug 678369, and fixes bug 147659 as a
convenient side-effect of using LaunchApp (which has the desired
fd-closing behavior already) rather than directly using fork/exec.
The main goal is to work around bug 227246, where PR_CreateProcess on
Unix interferes with anything else that tries to use child processes.
This does not fix that bug -- NSPR will still cause problems if used in
that way -- but it's an adequate workaround for that bug in Gecko in
almost all cases (the one known exception is nsAuthSambaNTLM, which uses
NSPR directly and needs to be fixed separately).
Waiting for the child process uses waitpid() directly, sharing the
existing code used for OS X.
MozReview-Commit-ID: 6zfZ1Zgk2i9
--HG--
extra : rebase_source : e8230503d82943af4563d8d63baa029d8a698683