The new names make it clearer that these actions apply to just one thread.
- profiler_sleep_start() --> profiler_thread_sleep()
- profiler_sleep_end() --> profiler_thread_wake()
- profiler_is_sleeping() --> profiler_thread_is_sleeping()
- GeckoProfilerSleepRAII --> GeckoProfilerThreadSleepRAII
- GeckoProfilerWakeRAII --> GeckoProfilerThreadWakeRAII
It's fairly straightforward, and measures the important parts of:
- Sampler, PseudoStack, ProfileBuffer, ThreadInfo.
- LUL, PriMap, SecMap
Coverage isn't perfect, but it gets the major things I found via DMD on Linux.
Example output in about:memory:
├──151.21 MB (49.73%) -- profiler
│ ├──141.49 MB (46.53%) ── lul
│ └────9.72 MB (03.20%) ── sampler
--HG--
extra : rebase_source : 67d2ada42aead43f68f5100a08204a1d1f1cfceb
For components also referencing it in code, see the blockers of bug 1336311.
MozReview-Commit-ID: 4tUZ24HKBWy
--HG--
extra : rebase_source : ec16149f525b9b7eaca7f96f1369929d21497121
Handling potential nsDeque size changes means a bit of extra work.
But if the nsDeque is const, we can assume that it shouldn't get modified, so
we can provide a more optimized iterator that doesn't need to handle size
changes.
Optimizing a range-for loop in which the deque is not modified, can be done
by writing: `for (void* item : const_cast<const nsDeque&>(deque)) {...}`
MozReview-Commit-ID: AFupjoTsoH3
--HG--
extra : rebase_source : a71b09c9cb73787ce686c7c762f92ef0c208e76a
Note that iterators stay at the same index if the deque size changes
(including end-iterators staying at the end).
This means that after front operations, iterators will effectively point at
different elements! (Possibly skipping or re-visiting some.)
But this is consistent with ForEach and hand-crafted index-based for loops.
MozReview-Commit-ID: 5IvazJR68dG
--HG--
extra : rebase_source : c574fd2d2642d784482698c0fc861269200d1059
We can make some assumptions now that the Input method is only called once and never again while a decode is pending.
MozReview-Commit-ID: EmzKEcwNY2J
--HG--
extra : rebase_source : 42ae59878962b425970a60abe25d98c023ef4fdf
Removing the exported symbols is straightforward enough.
The only wrinkle is that PeerConnectionCtx.cpp gets compiled with and
without MOZILLA_INTERNAL_API. When compiling without
MOZILLA_INTERNAL_API, mozilla::services::Get*Service was redirected to
the _external_* symbol variants. But as the _external_* symbols no
longer exist, PeerConnectionCtx.cpp's code no longer worked.
Fortunately, PeerConnectionCtx.cpp already contains a few #ifdef
MOZILLA_INTERNAL_API blocks to handle internal/external compilation;
fixing this newest issue was just a matter of extending existing blocks
and adding new ones. The key observation is that we never added any
observers when compiling without MOZILLA_INTERNAL_API, so we can #ifdef
out the removals of observers, as those would have no effect, and simply
skip getting the observer service for the observer additions if we're
compiling without MOZILLA_INTERNAL_API.
It's now possible to write:
for (void* item : deque) { ... }
MozReview-Commit-ID: FLoczCZd77y
--HG--
extra : rebase_source : 237293e94b478beb2bf352c1179d42c289dda145
The GMPLoader code was in plugin-container so that it was covered by
Adobe's voucher of plugin-container, but that's no longer necessary.
MozReview-Commit-ID: 3VRBAohRI9I
--HG--
extra : rebase_source : 58a30855ade14af4c4b1420edabd3abb398f232e
This could have been done more simply, but the small amount of
refactoring that takes place in this comment enables better error
messages in the case where something does go wrong.
There are several XPCOM tests that purport to call
NS_RegisterStaticAtoms. The tests located in the xpcom/tests/ directory
are unused, so we might as well just remove them. The gtests do get
run, but there's going to be no way to test NS_RegisterStaticAtoms once
sealing the atom table actually means forbidding new additions. So we
might as well remove the gtest too.
Also remove the #includes of some unused header files.
MozReview-Commit-ID: 6mRoIazEA3j
--HG--
extra : rebase_source : 6f96d22543509bf09b684b0bfbfa624eafc58b94
SHGetKnownFolderPath() is available on Windows Vista+ so we no longer need to GetProcAddress("SHGetKnownFolderPath"). We can set _WIN32_WINNT 0x0600 to expose the SHGetKnownFolderPath function declaration in shlobj.h and call it directly.
Also remove a redundant #include <shlobj.h>.
MozReview-Commit-ID: AoAlrfvQ5AB
--HG--
extra : rebase_source : 2fa3a0d3d122ca31fb3369a43a03b6e2c5d5dec2
This way we can't end up with a situation in which an ancestor doesn't care about skippability but a descendant does and doesn't get it, because the ancestor just claimed no skippability was needed.
Instead of lvalues, MozPromiseHolder::Resolve and Reject now take either
const& or && values of the expected types, to allow move semantics all the way
to the ResolveOrRejectValue object.
Note that we won't just take forwarding references of any type, as this could
lead to implicit conversions by bypassing the 'explicit' marker of the value
type constructors, like in bug 1331137.
MozReview-Commit-ID: K0jeY6WTXI1
--HG--
extra : rebase_source : 7ee0fd1edfdeadb239f48c8b5b46fd54af3ec5d2
MozPromise::All sets up 'Then' lambdas on all sub-promises, each one taking the
resolve/reject object by value.
Since this value will not be used again in the lambda, it is safe to Move it,
and from there MozPromiseHolder::Resolve/Reject can also Move it again into the
holder storage, potentially saving two copies per Resolve/Reject.
Also, once all sub-promises have been resolved, the resolve-values can be
Move'd into the joining promise's Resolve function.
MozReview-Commit-ID: 5oxgNEnE5lq
--HG--
extra : rebase_source : f0542055beb1434e7db384722c5123d888ca00e7
The aArgs parameter pack was already Forward'ed inside the constructor, so
maybe the '&&' was forgotten?
MozReview-Commit-ID: 7yg07axhZnp
--HG--
extra : rebase_source : dccd3ea5f0f1b6cadfe6bbc86c8ad34cb7f2c99e
Now that XRE_LibFuzzerGetFuncs is not used from outside libxul, it can
be inlined in LibFuzzerRunner::Run, simplifying things a little more.
--HG--
extra : rebase_source : 7a09f37444bf02983b232c964d85e7a866221f48
Going further from the previous changes, all libfuzzer_main really does
is call the init function, and then proceed to call the fuzzer driver
with the testing function.
So instead of calling that function for it to do all that, the
LibFuzzerRunner can just call the init function itself, and then
call the fuzzer driver with the testing function.
--HG--
extra : rebase_source : 2eb1a2ae763ef21827471cd32addceacefc1ac5d
The function given to XRE_LibFuzzerSetMain is called from somewhere that
does have access to argc/argv already, so we can avoid passing them
to XRE_LibFuzzerSetMain.
This actually might fix subtle issues with argc/argv not really matching
reality when calling the LibFuzzerMain function in the current code:
some arguments are handled before the call, and both argc and argv are
modified from within XRE_main, but the values stored for the
LibFuzzerMain call still are the original ones.
Argv being a pointer, and it not being reallocated, the value stored for
the LibFuzzerMain call points to the changed one, but argc, being an
integer, is not modified accordingly.
In fact, it's actually worse, because while the Gecko code doesn't
reallocate argv, gtk_main might. So if some GTK flag is passed on the
command line, there's also a possibility that the LibFuzzerMain function
will do a use-after-free.
So all in all, it's just better to use the set of modified argc/argv
from XRE_main instead of storing them from main().
--HG--
extra : rebase_source : 92b89909eab0fc2f67ce372b959bb0e3ed12cd2b
Nothing uses these defines, so we should remove them lest anybody get
confused. I would have also removed kAutoDetect (who would want to do
this?!), but kAutoDetect is used in one place in the tree, and I didn't
want to hold up the deletion of these two items with trying to fix that
one place.
Now that nothing is using those functions, we can remove them and limit
the scope of the standalone glue to initialize the new Bootstrap API.
--HG--
extra : rebase_source : b73845a207f8d6e632c46d089a00b7a67e1648fc
Reading application.ini involves using nsCOMPtr<nsIFile>, and that can
only happen through the XPCOM glue, which we eventually want to get rid
of.
So, while keeping the command line argument/environment variable
handling in nsBrowserApp, we move the actually parsing of the file to
XRE_main, where things can be handled without the XPCOM glue.
--HG--
extra : rebase_source : 487960a671476d4edae4f568c37efa6563ef4dff
Here, we also modify APKOpen to use the XPCOM glue loading process
instead of custom symbol resolution, so that the Bootstrap API can be
used in a more straightforward manner.
--HG--
extra : rebase_source : 55037ba30ca66a090b73923a3ce8df5b054bf47a
This is the first step towards changing how nsBrowserApp and other current
XPCOM glue users start up Gecko.
The goal here is to expose the same API via a single object with a
VTable instead of the current XPCOM glue machinery. Instead of creating
an entirely new API and changing everything to use it, we go forward
with smaller steps for a more comprehensible transition.
--HG--
extra : rebase_source : c2cf90ab3bb812b9ea75c70c9766f1a47ea50828
Instead of having nsBrowserApp.cpp set a flag in XREAppData to indicate
whether the DLL blocklist properly initialized, just have XRE code ask
the blocklist itself.
--HG--
extra : rebase_source : e872853481acce68b325909e476d009aec878701
This hasn't been used since the removal of the Metro code in bug
1039866, close to two years ago.
--HG--
extra : rebase_source : 58ec1ce63e4231c8006cafd3424675f14ddbf9f1
Back in bug 632404, when the function was added, preloading was
conditional. But after some A/B testing, the conclusion in bug 771745
was that we would just do preloading unconditionally.
Which means in practice, we don't need to have a function to enable it
manually anymore, since we're always enabling it.
--HG--
extra : rebase_source : c76307c13c057e87e1fe4564b82113fbfa20d382
OBSERVE_LATE_WRITES is now always defined, we can just remove it.
MozReview-Commit-ID: El6RnzZnXBN
--HG--
extra : rebase_source : 95fe63562b88c61ee5915e28a3a8b89c985042db
With frame pointer omission disabled we should always have usable stacks on Windows. This allows us to remove the MOZ_STACKWALKING define as it will always be enabled.
MozReview-Commit-ID: 54xs3Hf1r4P
--HG--
extra : rebase_source : dfaf13fb4c2185985f4f074c338ccf1fef8f3c94
In the 32-bit parisc runtime, the first four non floating-point
arguments are passed in registers (%r26, %r25, %r24 and %r23).
The remaining arguments are passed on the stack. There are four
reserved slots on the stack that the callee can use to save the
first four argument registers if the callee desires.
The StubN functions are special in that arguments are not explicitly
declared. %r26 is used for the "self" pointer. The call to SharedStub(n)
loads n into %r26 and clobbers the "self" pointer in %r26. The hppa
SharedStub implementation expects to find the "self" pointer on the
stack in the slot reserved for StubN. However, gcc doesn't copy any
arguments to the stack as no arguments are declared for StubN. Even
if it did, there's no guarantee that we could force gcc to save the
argument on the stack as that's more expensive than copying to a
free register. Thus, we need to copy %r26 to the stack slot manually.
Bug 1295053 removed most uses of NS_METHOD and NS_CALLBACK, but one use was
unintentionally left behind (in the XPIDL parser) and another has since crept
in (in MediaDrmCDMProxy.h).
So this patch removes NS_METHOD and NS_CALLBACK. NS_METHOD_(nsresult) and
NS_CALLBACK_(nsresult, T) can still be used for the same purpose, but those
alternatives are less likely to be used unintentionally.
--HG--
extra : rebase_source : a50fc7b2a64a36d1ca9beda81bc0edb8f2ec1934
In some parts of the crash reporter, we need to disable I/O
interposition, then turn it back on. We didn't have a function for
re-enabling the I/O interposer...until now.
This test alone would fail to even build without the previous patch,
demonstrating the issue at hand, where the method-pointer from the base class
forces NewRunnableMethod to store a pointer to that base class in a RefPtr,
which is not possible when that base class is not ref-counted.
MozReview-Commit-ID: 9XaQ8SwMqVo
--HG--
extra : rebase_source : 3ba0e13fb76ef2c5969084334c2f11e3f445d11f
This is done by storing the object pointer based on the exact pointee type,
instead of as hinted by the method-pointer, which could be a non-refcounted
base class.
The stored pointer type is statically-checked to be derived from (or the same
as) the class type from the method-pointer, to prevent misuses.
One change had to be done in TrackBuffersManager, as it was passing another
type and relying on implicit pointer conversions. A simple `.get()` to pass
the raw pointer type (to be stored in a RefPtr) fixed that one issue.
MozReview-Commit-ID: 4kH0XdjB5Rk
--HG--
extra : rebase_source : 40ad68820cfce469ecda272f430062f05dfcd09f
This test alone would fail to even build without the previous patch,
demonstrating the issue at hand, where the method-pointer from the base class
forces NewRunnableMethod to store a pointer to that base class in a RefPtr,
which is not possible when that base class is not ref-counted.
MozReview-Commit-ID: 9XaQ8SwMqVo
--HG--
extra : rebase_source : 5c752e1a16af8e8f976853396228abff2c76c43c
This is done by storing the object pointer based on the exact pointee type,
instead of as hinted by the method-pointer, which could be a non-refcounted
base class.
The stored pointer type is statically-checked to be derived from (or the same
as) the class type from the method-pointer, to prevent misuses.
One change had to be done in TrackBuffersManager, as it was passing another
type and relying on implicit pointer conversions. A simple `.get()` to pass
the raw pointer type (to be stored in a RefPtr) fixed that one issue.
MozReview-Commit-ID: 4kH0XdjB5Rk
--HG--
extra : rebase_source : 3eb7fa3cb1873f71b4d5e7118d2dc48f6fdf2874
Implemented in the same style as RemovePointer and RemoveSmartPointer, for
consistency.
It could have been done by invoking the latter two, but I didn't want to add an
unnecessary extra layer of templates; the cost of the code duplication should
be negligible.
MozReview-Commit-ID: IH4lZkbRYGZ
--HG--
extra : rebase_source : b9b9a07a03fab768fc88b300c33627b3179a81da
Just a straight move, no code changes.
This will be needed in bug 1329319, as some new code higher in the file will
rely on RemoveSmartPointer. Since the next patch will pretty much rewrite
RemoveSmartPointer anyway, I thought I might as well make the big move
right now, to keep better history/blame of the upcoming changes.
MozReview-Commit-ID: A2lMUFHFWg4
--HG--
extra : rebase_source : 8470a0f7e2e6892e9d9c2e4eef1c44d8f73d2dad
Then and ThenPromise can now be given only one member function, which takes a
`const MozPromise::ResolveOrRejectValue&`.
MozReview-Commit-ID: 5Zm0i27GHcA
--HG--
extra : rebase_source : 1ed068681616fa0aa5fa77f8dbf78ccbd727f363
Then and ThenPromise can now be given only one function object, which takes a
`const MozPromise::ResolveOrRejectValue&`.
MozReview-Commit-ID: BEtc3spK9Yh
--HG--
extra : rebase_source : 1b16ad15ebfcdfb653d8d98073adee0f8b27b46e
Removed 'virtual' from overrides, as per coding guidelines.
Fixed some incorrect indentations, and inconsistencies.
MozReview-Commit-ID: 4kNVgoDljG3
--HG--
extra : rebase_source : 7b25abacc7cfc1a6898963bc58120204c70bee45
As far as I can tell, this covers all the remaining threads which we start
using PR_CreateThread, except the ones that are created inside NSPR or NSS,
and except for the Shutdown Watchdog thread in nsTerminator.cpp and the
CacheIO thread. The Shutdown Watchdog thread stays alive past leak detection
during shutdown (by design), so we'd report leaks if we profiled it. The
CacheIO thread seems to stay alive past shutdown leak detection sometimes as
well.
This adds a AutoProfilerRegister stack class for easy registering and
unregistering. There are a few places where we still call
profiler_register_thread() and profiler_unregister_thread() manually, either
because registration happens conditionally, or because there is a variable that
gets put on the stack before the AutoProfilerRegister (e.g. a dynamically
generated thread name). AutoProfilerRegister needs to be the first object on
the stack because it uses its own `this` pointer as the stack top address.
MozReview-Commit-ID: 3vwhS55Yzt
--HG--
extra : rebase_source : 56dd27282e7bd09a7e7dc7ca09ccfe3a0198e7af
The point of this exercise is to make the thread name available in the thread
func of the thread, so that we can register the thread with the profiler from
the very start of its lifetime, and so that registration and unregistration
can be inside the same function.
MozReview-Commit-ID: DiiMKUQVr55
--HG--
extra : rebase_source : 24b15d56315ad49e72b3e9b76db7fb634f3bfe01
Bill McCloskey
Boris Zbarsky
Nicholas Nethercote
Jeff Walden
JW Wang
Sylvestre Ledru
Tom Tromey
Brian Hackett
Bevis Tseng
David Major
Vincent Lequertier
Michael Layzell
Wes Kocher
Olli Pettay
Sebastian Hengst
Carsten "Tomcat" Book
Honza Bambas
Gerald Squelart
Byron Campen [:bwc]
Jean-Yves Avenard
Nathan Froyd
Andrew McCreight
Chris Manchester
Jorg K
Chris Pearce
Emilio Cobos Álvarez
Benjamin Smedberg
Masatoshi Kimura
Phil Ringnalda
Gian-Carlo Pascutto
David Anderson
Geoff Brown
Chris Peterson
Kartikaya Gupta
Julian Seward
Mike Hommey
ffxbld
Mark Banner
Randell Jesup
Kris Maglione
Hiroyuki Ikezoe
Ben Kelly
Eric Rahm
John David Anglin
John Paul Adrian Glaubitz
Kate McKinley
Ryan VanderMeulen
Xidorn Quan
Markus Stange
Cervantes Yu