XPCOM's string API doesn't have the notion of a "null string". But it does have
the notion of a "void string" (or "voided string"), and that's what these
functions are returning. So the names should reflect that.
--HG--
extra : rebase_source : 4e3f982e0873877174a08a25413595ff66f7d20e
Because UBSan complains about casting -1:
> runtime error: load of value 4294967295, which is not a valid value for type 'JSGCParamKey'
--HG--
extra : rebase_source : ff972b29f9a89fcbe50d9f105196bcd8f06486bd
Because we want to remove nsAdoptingString. We have other variants that don't
use nsAdoptingString, which can be used instead. There are three basic
patterns.
1. The easiest case is when we don't check for success.
> nsAdoptingString s = Preferences::GetString("foo");
> foo(s);
becomes:
> nsAutoString s;
> Preferences::GetString("foo", s);
> foo(s);
2. The next case is when we check if the result is empty.
> nsAdoptingString s = Preferences::GetString("foo");
> if (s.IsEmpty()) { ... }
becomes:
> nsAutoString s;
> Preferences::GetString("foo", s);
> if (s.IsEmpty()) { ... }
3. The final case is when we null check the result.
> nsAdoptingString s = Preferences::GetString("foo");
> if (s) { ... }
becomes:
> nsAutoString s;
> nsresult rv = Preferences::GetString("foo", s);
> if (NS_SUCCEEDED(rv)) { ... }
The patch also avoids some UTF8/UTF16 conversions in a few places.
--HG--
extra : rebase_source : f339b1a3dda4dc93979d38c30c001fbe77485b55
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
For the Quatum DOM project, it's better to work in terms of event targets than
threads. This patch converts DOM code to operate on event targets rather than
threads, when possible.
MozReview-Commit-ID: 5FgvpKadUA2
Trackers use navigator.hardwareConcurrency as yet another source of entropy to fingerprint users. The Firefox Hardware Report says 70% of Firefox users have exactly 2 cores. When the privacy.resistFingerprinting pref is set, we want to blend into the crowd so spoof navigator.hardwareConcurrency = 2 to reduce user uniqueness. This pref was added in bug 1345322 for the Tor uplift project.
https://metrics.mozilla.com/firefox-hardware-report/#goto-cpu-and-memory
MozReview-Commit-ID: CDWAaxjRpqe
--HG--
extra : rebase_source : a24eabf1d0b0ea1706478306287634dae38a8c52
NS_SetCurrentThreadName() is added as an alternative to PR_SetCurrentThreadName()
inside libxul. The thread names are collected in the form of crash annotation to
be processed on socorro.
MozReview-Commit-ID: 4RpAWzTuvPs
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
Without this change, we will call WorkerPrefChanged if a pref whose name just
_starts_ with the name of one of our WORKER_SIMPLE_PREF prefs changes. Then in
WorkerPrefChanged we will get the value of the pref that changed, and store it
under the key identified by the closure, thus writing the value of an incorrect
pref in there.
MozReview-Commit-ID: JTsvvtC5P1o
Currently, JS sampling has major problems.
- JS sampling is enabled for all JS threads from the thread that runs
locked_profiler_start() -- currently only the main thread -- but the JS
engine can't handle enabling from off-thread, and asserts. This makes
profiling workers impossible in a debug build.
- No JS thread will be JS sampled unless enableJSSampling() is called, but that
only happens in locked_profiler_start(). That means any worker threads
created while the profiler is active won't be JS sampled.
- Only the thread that runs locked_profiler_stop() -- currently only the main
thread -- ever calls disableJSSampling(). This means that worker threads that
start being JS sampled never stop being JS sampled.
This patch fixes these three problems in the following ways.
- locked_profiler_start() now sets a flag in PseudoStack that indicates
JS sampling is desired, but doesn't directly enable it. Instead, the JS
thread polls that flag and enables JS sampling itself when it sees the flag
is set. The polling is done by the interrupt callback. There was already a
flag of this sort (mJSSampling) but the new one is better.
This required adding a call to profiler_js_operation_callback() to the
InterruptCallback() in XPCJSContext.cpp. (In comparison, the
InterruptCallback() in dom/workers/RuntimeService.cpp already had such a
call.)
- RegisterCurrentThread() now requests JS sampling of a JS thread when the
profiler is active, the thread is being profiled, and JS sampling is enabled.
- locked_profiler_stop() now calls stopJSSampling() on all live threads.
The patch makes the following smaller changes as well.
- Renames profiler_js_operation_callback() as profiler_js_interrupt_callback(),
because "interrupt callback" is the standard name (viz.
JS_AddInterruptCallback()).
- Calls js::RegisterContextProfilingEventMarker() with nullptr when stopping
JS sampling, so that ProfilerJSEventMarker won't fire unnecessarily.
- Some minor formatting changes.
--HG--
extra : rebase_source : 372f94c963a9e5b2493389892499b1ca205ebc2f
PseudoContext::sampleContext() is always called immediately after
profiler_get_pseudo_stack(). This patch introduces profiler_set_js_context()
and profiler_clear_js_context(), which replace the profiler_get_pseudo_stack()
+ sampleContext() pairs. This takes us a step closer to not having to export
PseudoStack outside the profiler.
--HG--
extra : rebase_source : 8558d1600eafd395cc696d31f3d21fb52a1a74b0
There is a single GeckoSampler and it is currently only accessed on the main
thread, so it's silly to use TLS for it; a normal global variable is better.
This patch also adds main thread assertions to a number of the profiler_*()
functions. Even though bug 1330184 may get rid of some of them, right now they
are a useful as both a sanity check and documentation.
--HG--
extra : rebase_source : 7613eb3cc8089b31180365f6463c81f4556c7b66