This function takes up quite a bit of space, and there's no need to for
the log getter to be inlined everywhere. Moving this to out-of-line
code saves ~200K on x86-64 Linux.
The current definition of MOZ_LOG requires calling
LazyLogModule::operator() multiple times, which is unnecessary. We can
avoid that with a bit of clever macro definition and a lengthy
explanation.
As our threattype-listname conversion design, "goog-harmful-proto" is allocated
for this new threat type. This threat type is mainly for mobile.
MozReview-Commit-ID: G9GbgmHHHfp
--HG--
extra : rebase_source : 0681fcd9322b94451a86eafe57bf1ccc4b89db30
extra : intermediate-source : 28b0502d9add81beeae58a2c33f9fd5839d4d544
extra : source : 646f02f15131aa98ad37015b0a641304a3271796
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 callback is only used in very limited ways, so just require that
the caller pass in the canonical supports pointer, plus the
participant. This probably won't affect performance much.
MozReview-Commit-ID: CsThzFsKyYx
--HG--
extra : rebase_source : 9595b1d75fc45bc5ee6d932a840e98b5d760cb78
The nsISupports objects added to the purple buffer are already
canonical, so we can avoid some overhead by not QIing them to
nsCycleCollectionISupports. This QIing overhead shows up in profiles.
MozReview-Commit-ID: CQN6wwc7MZm
--HG--
extra : rebase_source : 27e6b70f83b42b5db7af3d1e7d62e36d6f4013a0
All the SizeOf{In,Ex}cludingThis() functions take a MallocSizeOf function
which measures memory blocks. This patch introduces a new type, SizeOfState,
which includes a MallocSizeOf function *and* a table of already-measured
pointers, called SeenPtrs. This gives us a general mechanism to measure
graph-like data structures, by recording which nodes have already been
measured. (This approach is used in a number of existing reporters, but not in
a uniform fashion.)
The patch also converts the window memory reporting to use SizeOfState in a lot
of places, all the way through to the measurement of Elements. This is a
precursor for bug 1383977 which will measure Stylo elements, which involve
Arcs.
The patch also converts the existing mAlreadyMeasuredOrphanTrees table in the
OrphanReporter to use the new mechanism.
--HG--
extra : rebase_source : 2c23285f8b6c3b667560a9d14014efc4633aed51
This is basically a cosmetic change; references are the normal way to do string
outparams.
--HG--
extra : rebase_source : ffc5945f269bdcd3d4116755b56713e87a44b6cd
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
We already periodically calculate the ghost window amount after cycle
collection, this just uses a cached value of that for the distinguished amount.
This avoids the overhead of a recalculating the value when reporting telemetry.
This allows a bunch of other things to be removed too, including
PluginModuleParent::mSurrogateInstances,
PluginModuleChromeParent::sInstantiated, and NS_PLUGIN_INIT_PENDING.
The patch also removes the AsyncPluginInit crash annotation.
--HG--
extra : rebase_source : cadb1d215fd93051c9032ea0a1fb6f1d2fb80c6d
Implement nsMemoryReporterManager::GetHeapAllocatedAsync() by dispatching
nsMemoryReporterManager::GetHeapAllocated() to a thread pool and dispatching
the result back to the main thread to run the callback with the requested
attribute.
MozReview-Commit-ID: 9jj1UYqu5KD
--HG--
extra : rebase_source : a3620c6313b3253c41adff8d67c77a347240891b
extra : amend_source : 1732a5e4390fadbc597b6a61dc7d51e892f8441e
extra : histedit_source : b892d2046a07fe00368e8f1976394dc1f4c2f496
nsIMemoryReporter::getHeapAllocatedAsync() is added to get attribute
'heapAllocated' asynchronously.
MozReview-Commit-ID: 96KyZpCeTG1
--HG--
extra : rebase_source : 5c27b26788a3a96821ce054911dda8ce2932007d
extra : amend_source : fcb923dac2dfa9d7aa5bf520d38c5bb11f0d60e9
extra : histedit_source : 83ae65c153f7cef6c6529296838a9d9aa367219e
This requires:
- Moving the constructors of ProfilerMarkerPayload and its subclasses into the
.h file so they are visible even when ProfilerMarkerPayload.cpp isn't
compiled.
- Similarly, using a macro to make StreamPayload() a crashing no-op when the
profiler isn't enabled. (It is never called in that case.)
--HG--
extra : rebase_source : 7aad2fdb1bd4e49782024dba6664e8f992771520
It's silly to use prmem.h within Firefox code given that in our configuration
its functions are just wrappers for malloc() et al. (Indeed, in some places we
mix PR_Malloc() with free(), or malloc() with PR_Free().)
This patch removes all uses, except for the places where we need to use
PR_Free() to free something allocated by another NSPR function; in those cases
I've added a comment explaining which function did the allocation.
--HG--
extra : rebase_source : 0f781bca68b5bf3c4c191e09e277dfc8becffa09
This patch makes the following changes to the macros.
- Removes PROFILER_LABEL_FUNC. It's only suitable for use in functions outside
classes, due to PROFILER_FUNCTION_NAME not getting class names, and it was
mostly misused.
- Removes PROFILER_FUNCTION_NAME. It's no longer used, and __func__ is
universally available now anyway.
- Combines the first two string literal arguments of PROFILER_LABEL and
PROFILER_LABEL_DYNAMIC into a single argument. There was no good reason for
them to be separate, and it forced a '::' in the label, which isn't always
appropriate. Also, the meaning of the "name_space" argument was interpreted
in an interesting variety of ways.
- Adds an "AUTO_" prefix to PROFILER_LABEL and PROFILER_LABEL_DYNAMIC, to make
it clearer they construct RAII objects rather than just being function calls.
(I myself have screwed up the scoping because of this in the past.)
- Fills in the 'js::ProfileEntry::Category::' qualifier within the macro, so
the caller doesn't need to. This makes a *lot* more of the uses fit onto a
single line.
The patch also makes the following changes to the macro uses (beyond those
required by the changes described above).
- Fixes a bunch of labels that had gotten out of sync with the name of the
class and/or function that encloses them.
- Removes a useless PROFILER_LABEL use within a trivial scope in
EventStateManager::DispatchMouseOrPointerEvent(). It clearly wasn't serving
any useful purpose. It also serves as extra evidence that the AUTO_ prefix is
a good idea.
- Tweaks DecodePool::SyncRunIf{Preferred,Possible} so that the labelling is
done within them, instead of at their callsites, because that's a more
standard way of doing things.
--HG--
extra : rebase_source : 318d1bc6fc1425a94aacbf489dd46e4f83211de4
PROFILER_MARKER is now just a trivial wrapper for profiler_add_marker(). This
patch removes it.
--HG--
extra : rebase_source : 9858f34763bb343757896a91ab7ad8bd8e56b076
This patch reduces the differences between builds where the profiler is enabled
and those where the profiler is disabled. It does this by removing numerous
MOZ_GECKO_PROFILER checks.
These changes have the following consequences.
- Various functions and classes are now defined in all builds, and so can be
used unconditionally: profiler_add_marker(), profiler_set_js_context(),
profiler_clear_js_context(), profiler_get_pseudo_stack(), AutoProfilerLabel.
(They are effectively no-ops in non-profiler builds, of course.)
- The no-op versions of PROFILER_* are now gone. The remaining versions are
almost no-ops when the profiler isn't built.
--HG--
extra : rebase_source : 8fb5e8757600210c2f77865694d25162f0b7698a
mozilla::EditorBase stores nsISelectionController and nsIDocument with nsWeakPtr. However, nsWeakPtr requires QI to retrieve actual pointer and it makes some damage to the performance. If mozilla::WeakPter were available for them, it'd be great. However, it's not available with nsISelectionController nor nsIDocument because it's possible to implement SupportsWeakPtr only with their subclasses but the subclasses shouldn't be referred by editor. Therefore, this patch creates mozilla::CachedWeakPtr<class T> which stores both raw pointer (as cache) and nsWeakPtr and when its cache is requested, it checks if the object referred by nsWeakPtr is still alive.
Additionally, this patch hides the members from subclasses of EditorBase for reducing the maintenance cost.
MozReview-Commit-ID: FvtM7453Vv8
--HG--
extra : rebase_source : a524a8ea327c3993645fafa81db8aef65090f1e0
Once the |aPayload| argument to profile_add_marker() became a UniquePtr the
default value of nullptr caused compilation difficulties that could only be
fixed by #including ProfilerMarkerPayload.h into lots of additional places
(because the UniquePtr<T> instantiation required the T to be fully defined). To
get around this I just split profile_add_marker() into two functions, one with
1 argument and one with 2 arguments.
The patch also removes the definition of PROFILER_MARKER_PAYLOAD in the case
where MOZ_GECKO_PROFILER isn't defined. A comment explains why.
Bug 1368932 removed MOZ_STATIC_ASSERT_VALID_ARG_COUNT because it didn't
actually work for large numbers of arguments. But it was kind of useful
for macros that expand to something broken when they are given no
variadic argument at all.
Now that we have a macro that doesn't require tricks to count empty
arguments lists, however, we can use straightforward static_asserts
instead of a generic macro, which has the side effect of providing more
context in the error message.
--HG--
extra : rebase_source : 223f85c2c5cc7b3fa8c584b70bb084784fb5764a
In a couple places, MOZ_PASTE_PREFIX_AND_ARG_COUNT is used to only count
the number of arguments, we can now use MOZ_ARG_COUNT directly for that.
--HG--
extra : rebase_source : 1064e4cc231863dc4aff83ee6bc90d318b4be418
At the same time, remove the MOZ_STATIC_ASSERT_VALID_ARG_COUNT, which
doesn't actually work for more than 50 arguments(*), and which is now not
useful to detect 0 arguments.
(*) the build fails, but not directly thanks to the static_assert it
expands to.
--HG--
extra : rebase_source : 8f0fe7b352c89b5a3ec87f42ef5464c370c362ef
A previous bug missed a few places where we could theoretically
reenter the CC.
MozReview-Commit-ID: I0otlAEwyZa
--HG--
extra : rebase_source : 064b127a2c28a52b2807cd78031de9af4f258f60
Add breakpoint support for AArch64, and fix a scanf format specifier
warning. Also fix an #if line in xptcinvoke_arm.cpp to work as intended.
MozReview-Commit-ID: BSjYVD8Zq0t
This annotates vsprintf-like functions with MOZ_FORMAT_PRINTF. This may
provide some minimal checking of such calls (the GCC docs say that it
checks for the string for "consistency"); but in any case shouldn't
hurt.
MozReview-Commit-ID: HgnAK1LiorE
--HG--
extra : rebase_source : 9c8d715d6560f89078c26ba3934e52a2b5778b6a
See also bug 1361495 - PR_SI_HOSTNAME is implemented in NSPR on
Windows as initializing winsock which can be janky. There don't seem
to be any users of this property, and it has tracker concerns anyhow -
so remove it.
MozReview-Commit-ID: S2AwzMUgYk
--HG--
extra : rebase_source : 552bed219913f40c002b807be3239d4666a5284b
When we just had CycleCollectedJSContext (and no CycleCollectedJSRuntime) a
weird thing happened at shutdown:
1. We would call JS_DestroyContext from ~CycleCollectedJSContext. By that time,
the ~XPCJSContext destructor had already finished.
2. Destroying the context runs a final GC. That GC would call back into various
GC callbacks, such as TraceBlackJS and TraceGrayJS.
3. These callbacks would do a virtual method call:
http://searchfox.org/mozilla-central/rev/876c7dd30586f9c6f9c99ef7444f2d73c7acfe7c/xpcom/base/CycleCollectedJSRuntime.cpp#791
4. Normally this method call would call into
XPCContext::TraceNativeBlackRoots. However, C++ changes the vtable for an
object during destruction. So we would only call CycleCollectedJSContext's
version of TraceNativeBlackRoots, which is empty. So we never traced anything.
When I moved this code into the runtime, we actually do call into
XPCJSRuntime::TraceNativeBlackRoots at that time. So the behavior changed, and
that was causing crashes once I nulled out the TLS as you asked. So I removed
these callbacks for the last GC.
MozReview-Commit-ID: 3do13bjpwQj
This patch keeps a list of all the cooperatively scheduled contexts that are
linked to a runtime. In places where we need to iterate over all contexts (for
GC, specifically), it iterates over the list.
MozReview-Commit-ID: 3pKJX78f2l0
This change moves most of the logic for the threadsafety check into
nsAutoOwningThread, rather than having part of the logic live in
nsAutoOwningThread and part of the logic live in nsDebug.h. Changing
this also forces us to clean up a couple of places that replicated the
logic that lived in nsDebug.h as well.
Change mozilla::Smprintf and friends to return a UniquePtr, rather than
relying on manual memory management. (Though after this patch there are
still a handful of spots needing SmprintfFree.)
MozReview-Commit-ID: COa4nzIX5qa
--HG--
extra : rebase_source : ab4a11b4d2e758099bd0794d5c25d799a7e42680
To run JS in separate cooperative threads, we need to split up per-thread state
from per-runtime state. This patch does that for XPConnect.
MozReview-Commit-ID: 407SlJ7nR6v
This is necessary to allow helper threads to attempt large allocations and recover from fragmentation situations with the LargeAllocationFailureCallback.
MozReview-Commit-ID: AyA3pbXcaYy
--HG--
extra : rebase_source : 7a5feb779b690ec7f123481e76f2390c850dac91
The header uses nsDataHashtable, but not nsTHashtable.
MozReview-Commit-ID: 1wxmqjTyPMS
--HG--
extra : rebase_source : 869a63c52f688e731343fab7ae0b1f3f9eaec5da
This patch makes the error codes in nsError.h be generated by a python script.
This gives us the opportunity to add rust code generation in parallel with the
C++ code generation, which will happen in part 2.
This patch also reworks the name calculation in ErrorNames.cpp to use generated
code by the python script.
MozReview-Commit-ID: 5wxbdZwxe7q
This patch makes the error codes in nsError.h be generated by a python script.
This gives us the opportunity to add rust code generation in parallel with the
C++ code generation, which will happen in part 2.
This patch also reworks the name calculation in ErrorNames.cpp to use generated
code by the python script.
MozReview-Commit-ID: 5wxbdZwxe7q
This uses std::atomic rather than mozilla::Atomic since mozilla::Atomic
does not support using different memory synchronization for different
atomic operations on the same variable.
The added comments could use careful review since, while they reflect my
understanding of the issue, I don't consider myself an expert on the
topic.
MozReview-Commit-ID: 7xByCXt17Dr
--HG--
extra : transplant_source : %8DM%88%E8%B7%B4%D8a%D6%F5%3F%9B%DC%09X%F3%7C%98%DE%21
This uses std::atomic rather than mozilla::Atomic since mozilla::Atomic
does not support using different memory synchronization for different
atomic operations on the same variable.
The added comments could use careful review since, while they reflect my
understanding of the issue, I don't consider myself an expert on the
topic.
MozReview-Commit-ID: 7xByCXt17Dr
--HG--
extra : transplant_source : 8%8Ci%CC%EA%0F%CF%C7%3E%F1%93%F5%C9%ED9%84%F9%3Evx
For testing purposes it will be useful to be able to trigger crashes in Rust
code. Being able to trigger a panic seems like a good place to start. This
will make it easier to validate improvements in crash reporting.
MozReview-Commit-ID: Bh5rBieLLWW
--HG--
rename : toolkit/crashreporter/test/unit/test_crash_moz_crash.js => toolkit/crashreporter/test/unit/test_crash_rust_panic.js
extra : rebase_source : ba9f626ca2d2852f966e93401b8f8f7543615310
extra : source : 8c9117de1e7f40af42b7cbce25bc3780c032fe45
For testing purposes it will be useful to be able to trigger crashes in Rust
code. Being able to trigger a panic seems like a good place to start. This
will make it easier to validate improvements in crash reporting.
MozReview-Commit-ID: Bh5rBieLLWW
--HG--
rename : toolkit/crashreporter/test/unit/test_crash_moz_crash.js => toolkit/crashreporter/test/unit/test_crash_rust_panic.js
extra : rebase_source : 0ac96469629a7a933fcf3bf6720c448db45543eb
extra : source : 8c9117de1e7f40af42b7cbce25bc3780c032fe45
It's a very general mechanism for replacing the implementation of
printf_stderr().
It's primarily used by the profiler, sparingly, and not in an important way.
Worse, it prevents us from using MOZ_LOG in the profiler, which is something I
want. Because if any code that locks gPSMutex also calls MOZ_LOG, that then
calls printf_stderr(), which calls profiler_log(), which locks gPSMutex, which
deadlocks.
The only other use of set_stderr_callback() is for the ultra-hacky,
for-local-use-only copy_stderr_to_file() function, which was added for B2G
debugging and is no longer necessary.
This patch removes set_stderr_callback() altogether.
--HG--
extra : rebase_source : d31ecb482fe5899f62dc56a38e87d91f9271bab0
There's an antipattern where nsLiteralString is used as an unnecessary intermediary in converting from CharT* to CharT*,
e.g. CallAFunctionThatTakesACharPointer(NS_LITERAL_CSTRING("foo").get());
or
NS_NAMED_LITERAL_STRING(foo, "abc");
CallAFunctionThatTakesACharPointer(foo.get());
This patch rewrites the callsites that can be trivially changed to use char*/char16_t*.
I'd somewhat like to remove nsTLiteralString::get() altogether, but in code that's less straightforward than these examples, get() is useful enough to keep.
MozReview-Commit-ID: Kh1rUziVllo
--HG--
extra : rebase_source : c21a65694d6e1c42fd88f73632f7ac8f38d005ae
There's an antipattern where nsLiteralString is used as an unnecessary intermediary in converting from CharT* to CharT*,
e.g. CallAFunctionThatTakesACharPointer(NS_LITERAL_CSTRING("foo").get());
or
NS_NAMED_LITERAL_STRING(foo, "abc");
CallAFunctionThatTakesACharPointer(foo.get());
This patch rewrites the callsites that can be trivially changed to use char*/char16_t*.
I'd somewhat like to remove nsTLiteralString::get() altogether, but in code that's less straightforward than these examples, get() is useful enough to keep.
MozReview-Commit-ID: Kh1rUziVllo
--HG--
extra : rebase_source : c21a65694d6e1c42fd88f73632f7ac8f38d005ae
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
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
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.
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
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
NS_LogCOMPtrAddRef and NS_LogCOMPtrRelease always pass false to
GetSerialNumber, because they pass in everything they get without
regard to whether it is being logged or not, so they don't want to
create a serial number if none exists. This causes the assertions
added in bug 1309051 to be hit. To work around this, I hoist the
assertion into the other callers of this method. Two of them already
had this check, but it was non-fatal.
This also makes the asserts not happen in release builds, as I decided
it doesn't really matter what happens if somebody tries to use it
there.
--HG--
extra : rebase_source : 5e70290492fd442b79b4d40c300a263e322f485b
With the added safety checks it's unlikely that anything in this function will
fire ObjC exceptions, but our rule is to have guards around every Objective C
function that can directly be called from C++ files.
MozReview-Commit-ID: GQ0bN5638Sf
--HG--
extra : rebase_source : 3919f4a2b8160f197e1690ba13b58319239848e1
extra : source : 3d233eddd929e0cb2cadf0b07f75d60aa3fba419
This potentially changes behavior. On my machine, the old code returned
NS_ERROR_FAILURE because the dictionary did not have a "countryCode" entry,
but this new implementation correctly returns the string "CA".
MozReview-Commit-ID: 17Vme0fcAIw
--HG--
extra : rebase_source : 9ffc388ae98b11cb37c37957a8721e92284208c3
extra : source : e1a14b0c638571ec7f7aaec56f11d4b77dfb4dd5
NS_FOUND_TARGET is now declared as an error code. However, making it as a success code makes the code simpler.
First, this patch renames it to NS_SUCCESS_EDITOR_FOUND_TARGET because it's usual naming rule (according to the other declarations).
Next, FindTargetNode() should return it when a nest call of itself returns NS_SUCCESS_EDITOR_FOUND_TARGET as it does now.
Finally, removing the code overwriting NS_FOUND_TARGET with NS_OK from HTMLEditor::CreateDOMFragmentFromPaste() since it doesn't cause hitting NS_ENSURE_SUCCESS() and the variable, rv, will be overwritten with other method's result.
MozReview-Commit-ID: 6GgZptrXXQa
--HG--
extra : rebase_source : 79418fc83fb087e559221f895c59c7c334980456
This is an unrelated change to fix an issue that was bothering me.
MozReview-Commit-ID: Cxw9WhHfSAf
--HG--
extra : rebase_source : 10e3b3f28ecad0af216dbb368ffdb3b0ff75c7f9
Nobody asks for the new stats, only the total ones, so there's no need
for two sets of statistics.
MozReview-Commit-ID: AO0ue9MPn3N
--HG--
extra : rebase_source : 8d5237c4efdc0ece5bf1a386cae38e394aaadf01
Only about:bloat used NEW_STATS, so act like we have ALL_STATS
everywhere. A later patch will remove the mNewStats field.
MozReview-Commit-ID: LUJBpS3iYht
--HG--
extra : rebase_source : 543951314e12e7964e3f25c155b658d50ce674a6
DumpStatistics does not track any objects that are created or
destroyed while it is running, which means that any subsequent calls
to it will produce incorrect results. This can lead to incorrect
positive or negative leaks being reported. See 1271182.
Now that about:bloat has been removed, DumpStatistics should only be
called once, during shutdown.
MozReview-Commit-ID: IjMkExeBRBr
--HG--
extra : rebase_source : 5966789c2febfedc796d17f8589e8c3703d266cb
* Only allows setting the log file at runtime if not set by an Env Var
* LogModulePrefWatcher will watch logging.config. prefs and call into Logging.cpp to set the log file, sync or timestamp
* Log files set by pref will have a -main.PID or -child.PID suffix
* If the logging.config.clear_on_startup pref is true, prefs will be reset upon restart.
MozReview-Commit-ID: CWJujX4jm2A