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
We were using a StaticRefPtr without it being fully defined for
SystemGroupImpl::sSingleton, resulting in a non-unified build failure.
MozReview-Commit-ID: AgSuVvGTri7
--HG--
extra : rebase_source : 906e30e8c2c21e13a045a941e9d92e1d2d2af079
Currently the Gecko Profiler defines a moderate amount of stuff when
MOZ_GECKO_PROFILER is undefined. It also #includes various headers, including
JS ones. This is making it difficult to separate Gecko's media stack for
inclusion in Servo.
This patch greatly simplifies how things are exposed. The starting point is:
- GeckoProfiler.h can be #included unconditionally;
- everything else from the profiler must be guarded by MOZ_GECKO_PROFILER.
In practice this introduces way too many #ifdefs, so the patch loosens it by
adding no-op macros for a number of the most common operations.
The net result is that #ifdefs and macros are used a bit more, but almost
nothing is exposed in non-MOZ_GECKO_PROFILER builds (including
ProfilerMarkerPayload.h and GeckoProfiler.h), and understanding what is exposed
is much simpler than before.
Note also that in BHR, ThreadStackHelper is now entirely absent in
non-MOZ_GECKO_PROFILER builds.
This adds an attribute 'noShell' to nsIProcess that is used to launch a process
using CreateProcess() if we are sure we are launching an executable and don't
require the extra work of the Windows shell service.
MozReview-Commit-ID: 7p0iHCZK1uX
Defining get() in the declaration of nsThreadManager 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.
By doing this we avoid triggering assertions in the Servo code that ensure
we have registered the thread with Servo and set the proper state on it.
MozReview-Commit-ID: K6qHrYoQDLm
--HG--
extra : rebase_source : d01b0aad42273f6b92b7cfd5f5fe17ffe7b4cda0
Unfortunately, this needed some additional trickery in order to keep its
constructor "private". I stole this trick from [1]. With this patch, we tear
down the statistics object during XPCOM shutdown intead of after it. I don't
believe that we need the object to live past the ClearOnShutdown destructors.
[1] http://rienajouter.blogspot.com/2014/10/makeshared-and-makeunique-for-classes.html
MozReview-Commit-ID: JsiN6Bq9Yp4
--HG--
extra : rebase_source : dd26c8e6906a6c9fd500c28379f8c63fd7c3ad6a
do_CreateInstance was used without prior declaration.
MozReview-Commit-ID: 4LkXAcZytM7
--HG--
extra : rebase_source : a983330be02ed058a109ba3bbfd6ecdd3f2ddf56
LabeledEventQueue was used without prior declaration.
MozReview-Commit-ID: 3aqGDb0cZFY
--HG--
extra : rebase_source : 08e207b2024e5ba1be1eb0c55ddbe7b0fc405637
AbstractThread was used without prior declaration.
MozReview-Commit-ID: BmP83mmjX3b
--HG--
extra : rebase_source : 4f079246b7dd6c378eba97897f74a3c9623540df
nsIThreadObserver (defined in nsIThreadInternal.h) was used without prior
declaration.
MozReview-Commit-ID: 9cSuERgUPtl
--HG--
extra : rebase_source : 15219cba6f5a41c42aa1103d8c958a55ac3b9af0
nsTArray and EventLoopActivation were used without prior declaration.
MozReview-Commit-ID: C05YG6Nzh52
--HG--
extra : rebase_source : 3f78b6a1d73f4d59d3aac4b2da79c27cae404897
The LinkedList.h header is requires for the sSchedulerGroups variable
declaration.
MozReview-Commit-ID: 6T0WPKQER9S
--HG--
extra : rebase_source : 545e60bdec4e186a03cb20e342e561e104abcd98
InputEventStatistics::Get() requires the InputEventStatistics.h #include.
MakeScopeExit() requires the ScopeExit.h #include.
LabeledEventQueue.h is required for the PrioritizedEventQueue class.
MozReview-Commit-ID: 7gRwhV3YQXw
--HG--
extra : rebase_source : 54b56317b2876db2ed679e9f47ffb87fdf83cdd2
The nsTArray type was used without prior declaration.
MozReview-Commit-ID: KMUgXO2kBIY
--HG--
extra : rebase_source : 671ffe885ae7220bff746d433f55196519d05b8c
nsIRunnable was used without prior declaration.
MozReview-Commit-ID: CVEkaw6xBsC
--HG--
extra : rebase_source : 06c71dfada5e26725d7771284a9f400bf7b5fdd8
nsCOMPtr and nsThreadPoolNaming types were used without prior
declaration.
MozReview-Commit-ID: Gt7gksujs13
--HG--
extra : rebase_source : 57bbdb4f0d7ae0789dfc095fd4b6c99ad780f1ad
do_CreateInstance was used without prior declaration.
MozReview-Commit-ID: 4LkXAcZytM7
--HG--
extra : rebase_source : ff47c25472aec22889b8f42822ac49091c3706cf
LabeledEventQueue was used without prior declaration.
MozReview-Commit-ID: 3aqGDb0cZFY
--HG--
extra : rebase_source : e247b49b646f714e38dedb6a93d1b499e01b0c5a
AbstractThread was used without prior declaration.
MozReview-Commit-ID: BmP83mmjX3b
--HG--
extra : rebase_source : 3687625921e1d5e589f8e59901f75bf72a8d4c91
nsIThreadObserver (defined in nsIThreadInternal.h) was used without prior
declaration.
MozReview-Commit-ID: 9cSuERgUPtl
--HG--
extra : rebase_source : b7a3a47114680dbb69c9d0f17fa75ebbc8f444dc
nsTArray and EventLoopActivation were used without prior declaration.
MozReview-Commit-ID: C05YG6Nzh52
--HG--
extra : rebase_source : e939b277fbeb11d82af21c077faecd82af0697c6
The LinkedList.h header is requires for the sSchedulerGroups variable
declaration.
MozReview-Commit-ID: 6T0WPKQER9S
--HG--
extra : rebase_source : 23f442b30d8a9160c08b52b38800e891748b4367
InputEventStatistics::Get() requires the InputEventStatistics.h #include.
MakeScopeExit() requires the ScopeExit.h #include.
LabeledEventQueue.h is required for the PrioritizedEventQueue class.
MozReview-Commit-ID: 7gRwhV3YQXw
--HG--
extra : rebase_source : a94bbd653143ead43a317ba6470beb6d99ab584d
The nsTArray type was used without prior declaration.
MozReview-Commit-ID: KMUgXO2kBIY
--HG--
extra : rebase_source : 3bdca144a43ef7353ef9a62f94dfdc6dc2adfcc0
nsIRunnable was used without prior declaration.
MozReview-Commit-ID: CVEkaw6xBsC
--HG--
extra : rebase_source : 95b377eda3befeed66f37e6833a680ae4333303c
nsCOMPtr and nsThreadPoolNaming types were used without prior
declaration.
MozReview-Commit-ID: Gt7gksujs13
--HG--
extra : rebase_source : 18c5572548dc181ffe921154d9da00113a5e0090
Properly enclose all relevant details of CPUUsageWatcher in ifdefs
which control whether it should be active or not. Additionally,
apparently clock_gettime is not defined on OSX prior to 10.12, so
this is failing to compile for OSX on the build server, but not
locally. However, clock_get_time and getrusage should cover our
use cases sufficiently.
MozReview-Commit-ID: Ffi6yXLb9gO
--HG--
extra : rebase_source : 84f9cf3b2074883dc6fe6d5a50ff27ffdb008a4f
We would like to be able to see if a given hang in BHR occurred
under high CPU load, as this is an indication that the hang is
of less use to us, since it's likely that the external CPU use
is more responsible for it.
The way this works is fairly simple. We get the system CPU usage
on a scale from 0 to 1, and we get the current process's CPU
usage, also on a scale from 0 to 1, and we subtract the latter
from the former. We then compare this value to a threshold, which
is 1 - (1 / p), where p is the number of (virtual) cores on the
machine. This threshold might need to be tuned, so that we
require an entire physical core in order to not annotate the hang,
but for now it seemed the most reasonable line in the sand.
I should note that this considers CPU usage in child or parent
processes as external. While we are responsible for that CPU usage,
it still indicates that the stack we receive from BHR is of little
value to us, since the source of the actual hang is external to
that stack.
MozReview-Commit-ID: JkG53zq1MdY
--HG--
extra : rebase_source : 16553a9b5eac0a73cd1619c6ee01fa177ca60e58
In some unknown circumstance, possibly if the parent process has a
different version than the child process, the child does not receive
scheduler prefs, which makes it read out of an uninitialized local
variable. This can probably happen because the scheduler prefs are
checked before we do the ContentChild::Init version check. Bill also
suggested that the pref env var might be getting truncated.
This patch improves on the situation by using null for the prefs array
if none was sent, and falling back on the default values, which leave
the scheduler disabled.
This also checks that the pref string is at least long enough to avoid
a buffer overflow. Note that if the end of the string isn't an integer
we'll end up with an sPrefThreadCount of zero, which can't be good.
MozReview-Commit-ID: ByHLFMEpgyZ
--HG--
extra : rebase_source : 8f6368b88ec3746f4d1c7716a962bb2ac3c2f3b5
The class, in practice, was already doing nothing in that case, but with
it being half #ifdef'ed on EARLY_BETA_OR_EARLIER, that led to build
failures for unused code on late beta. Just remove the class completely
on late beta.
--HG--
extra : rebase_source : 801b0b9bb9faf41270f72f616e720d5725e8b25c
The return of these functions is actually (DWORD) –1
MozReview-Commit-ID: 112d6BTBt8O
--HG--
extra : rebase_source : f36ec05d9a1e85d4d2dd844d8024189971aaeb46
This patch refactors the nsThread event queue to clean it up and to make it easier to restructure. The fundamental concepts are as follows:
Each nsThread will have a pointer to a refcounted SynchronizedEventQueue. A SynchronizedEQ takes care of doing the locking and condition variable work when posting and popping events. For the actual storage of events, it delegates to an AbstractEventQueue data structure. It keeps a UniquePtr to the AbstractEventQueue that it uses for storage.
Both SynchronizedEQ and AbstractEventQueue are abstract classes. There is only one concrete implementation of SynchronizedEQ in this patch, which is called ThreadEventQueue. ThreadEventQueue uses locks and condition variables to post and pop events the same way nsThread does. It also encapsulates the functionality that DOM workers need to implement their special event loops (PushEventQueue and PopEventQueue). In later Quantum DOM work, I plan to have another SynchronizedEQ implementation for the main thread, called SchedulerEventQueue. It will have special code for the cooperatively scheduling threads in Quantum DOM.
There are two concrete implementations of AbstractEventQueue in this patch: EventQueue and PrioritizedEventQueue. EventQueue replaces the old nsEventQueue. The other AbstractEventQueue implementation is PrioritizedEventQueue, which uses multiple queues for different event priorities.
The final major piece here is ThreadEventTarget, which splits some of the code for posting events out of nsThread. Eventually, my plan is for multiple cooperatively scheduled nsThreads to be able to share a ThreadEventTarget. In this patch, though, each nsThread has its own ThreadEventTarget. The class's purpose is just to collect some related code together.
One final note: I tried to avoid virtual dispatch overhead as much as possible. Calls to SynchronizedEQ methods do use virtual dispatch, since I plan to use different implementations for different threads with Quantum DOM. But all the calls to EventQueue methods should be non-virtual. Although the methods are declared virtual, all the classes used are final and the concrete classes involved should all be known through templatization.
MozReview-Commit-ID: 9Evtr9oIJvx
HangAnnotations was very complex, required a separate allocation, and used this
unfortunate virtual interface implementation which made it harder to do
interesting things with it (such as serialize it over IPC).
This new implementation is much simpler and more concrete, making
HangAnnotations simply be a nsTArray<Annotation>. This also simplifies some of
the IPC code which was added in part 7.
MozReview-Commit-ID: EzaaxdHpW1t
These will be used to implement IPC serialization and deserialization of the
HangDetails object to send over IPC. This is a temporary measure as
HangAnnotations is rewritten in part 11.
MozReview-Commit-ID: 1WHNvhDrMF5
The test helper_touch_action_regions.html uses nsDOMWindowUtils to synthesize native input events and creates some runnables to trigger the test. It expects the runnables which synthesize native input events are processed first, then the runnables to continue the test, and finally the input events are forwarded from chrome process to content process. Enabling event prioritization may change the execution order.
Wraps those runnables to synthesize native input events as priority=input and dispatches those runnables to continue the test with priority=input to make sure the execution order is as expected.
MozReview-Commit-ID: 8hkaB1FRW9T
SchedulerGroup dispatch needs to replicate all the quirks of dispatching
directly to threads, which means we need to handle cases where dispatch
might have failed and we have resources that we don't want to leak.
This patch is mainly to make IdleTaskRunner reusable by nsHtml5TreeOpExecutor.
The only necessary work to that purpose is to remove the dependency of
sShuttingDown, which was a static variable in nsJSEnvironment.cpp.
The idea is to have a "MayStopProcessing" as a callback for the consumer to
return sShuttingDown.
In addition to sShuttingDown, we use std::function<bool()> as the runner
main callback type.
MozReview-Commit-ID: FT2X1unSvPS
--HG--
extra : rebase_source : 3fe2d4f597f53e9a90f3dc8d5009df04240534ba
extra : intermediate-source : 41f6715c344ce26f7820cecb2544db8c50dca796
extra : source : 042f10937305e34245bdaf75dcb816db7738254e
Nothing is changed in this patch except for renaming and code move around.
The strategy is to have the final file setup in this patch without any
detail change. The actual code change will be in the next patch so that
we can focus on reviewing the diff in the next patch regarding IdleTaskRunner.
MozReview-Commit-ID: 4Bul9mZ7z1n
--HG--
extra : rebase_source : b978da3a3c68da58f9fd93502bcc4295acd699ce
extra : source : 833d4b69accbf7d1d60f9f11d807ee37d608b6fe
MozStackWalk() is different on Windows to the other platforms. It has two extra
arguments, which can be used to walk the stack of a different thread.
This patch makes those differences clearer. Instead of having a single function
and forbidding those two arguments on non-Windows, it removes those arguments
from MozStackWalk, and splits off MozStackWalkThread() which retains them. This
also allows those arguments to have more appropriate types (HANDLE instead of
uintptr_t; CONTEXT* instead of than void*) and names (aContext instead of
aPlatformData).
The patch also removes unnecessary reinterpret_casts for the aClosure argument
at a couple of MozStackWalk() callsites.
--HG--
extra : rebase_source : 111ab7d6426d7be921facc2264f6db86c501d127
This parameter isn't used by any implementation of onDispatchedEvent,
and keeping the parameter makes later refactorings in this bug more difficult.
MozReview-Commit-ID: 90VY2vYtwCW
This is similar like the previous patch, but for the 8-bit string variants.
Also, it changes assignment to Adopt() in GetCString() and GetDefaultCString()
to avoid an extra copy.
--HG--
extra : rebase_source : eba805c3a7b809d5ccd6e853b1c9010db9477667
It's just a complex wrapper for free(), or equivalent function. (In practice,
all the uses end up in free().)
--HG--
extra : rebase_source : 247ea8458aa57319bd1c8366115a9b4f39ed5a33
The test helper_touch_action_regions.html uses nsDOMWindowUtils to synthesize native input events and creates some runnables to trigger the test. It expects the runnables which synthesize native input events are processed first, then the runnables to continue the test, and finally the input events are forwarded from chrome process to content process. Enabling event prioritization may change the execution order.
Wraps those runnables to synthesize native input events as priority=input and dispatches those runnables to continue the test with priority=input to make sure the execution order is as expected.
MozReview-Commit-ID: 8hkaB1FRW9T
As well as the straightforward things, this lets us remove ReadSysFile and
WriteSysFile, which in turn lets us remove TestFileUtils.cpp.
--HG--
extra : rebase_source : fc90c05352e654ffc41009d8504a9c54f394fc3f
For some reason, I continuously ran into windows x64 specific failures when
trying to read this heap allocated data while the main thread was paused. I
don't know specifically how this happened, but I am able to avoid it by instead
directly allocating the buffer in a `mozilla::Array` in static storage, and
copying that data instead.
MozReview-Commit-ID: 473d6IpHlc4
Unfortunately during shutdown we can sometimes leak the runnable passed into
SystemGroup::Dispatch. It is leaked instead of being freed off main thread
because we sometimes are passing data which can only be freed on the main thread
safely to the main thread, and running the destructor on the wrong thread could
be really bad.
This is a really really gross workaround for that issue which helps to avoid the
XPCOM leak checker failures which were appearing on try.
MozReview-Commit-ID: GTfdxKnsTae
This involved a change to BackgroundHangMonitor, as it initialized sDisabled
incorrectly to false, instead of true, We need sDisabled initialized to true, as
we cannot assume that it is enabled until BackgroundHangMonitor::Startup() is
called.
MozReview-Commit-ID: 94slLTkNk3C
