Sometimes when we call ShutdownWithTimeout on a thread pool, the unresponsive
thread that we leak will actually complete before the main thread is done.
In that case, the thread will dereference the thread shutdown context, so
we must intentionally leak it too.
Differential Revision: https://phabricator.services.mozilla.com/D10645
This method is necessary because some threads might be stuck making blocking
calls. This means the thread is not processing any events, and we're unable
to safely terminate it. Our solution here is to leak the stuck threads
instead of waiting for them and potentially causing a shutdown hang.
Differential Revision: https://phabricator.services.mozilla.com/D9601
--HG--
extra : moz-landing-system : lando
In the current code there are 3 main issues:
1. nsFileStream is not really thread-safe. There is nothing to protect the
internal members and we see crashes.
2. nsPipeInputStream doesn't implement ::Seek() method and that caused issues
in devtools when a nsHttpChannel sends POST data using a pipe. In order to fix
this, bug 1494176 added a check in nsHttpChannel: if the stream doesn't
implement ::Seek(), let's clone it. This was an hack around nsPipeInputStream,
and it's bad.
3. When nsHttpChannel sends POST data using a file stream, nsFileStream does
I/O on main-thread because of the issue 2. Plus, ::Seek() is called on the
main-thread causing issue 1.
Note that nsPipeInputStream implements only ::Tell(), of the nsISeekableStream
methods. It doesn't implement ::Seek() and it doesn't implement ::SetEOF().
With this patch I want to fix point 2 and point 3 (and consequentially issue 1
- but we need a separate fix for it - follow up). The patch does:
1. it splits nsISeekableStream in 2 interfaces: nsITellableStream and
nsISeekableStream.
2. nsPipeInputStream implements only nsITellableStream. Doing this, we don't
need the ::Seek() check for point 2 in nsHttpChannel: a simple QI check is
enough.
3. Because we don't call ::Seek() in nsHttpChannel, nsFileStream doesn't do I/O
on the main-thread, and we don't crash doing so.
In FxAccountsComponents.manifest, the previous line registers the
component CID, but only for the main process. This means we hit an
error while parsing the manifest in the child process, because the CID
is not recognized. The fix is simply to not try to use the CID to
register the contract in the child process.
As for the rest of the changes, since bug 1438688, XPT information is
compiled into the Firefox binary, so the interfaces manifest entry is
no longer needed. This patch removes instances of this line from
manifest files. This makes some manifest files empty, so the patch
also removes the now-empty files.
Differential Revision: https://phabricator.services.mozilla.com/D8751
--HG--
extra : moz-landing-system : lando
In TestEventTargetQI.cpp, nsIThreadPool is a subclass of
nsIEventTarget, so we cannot QI from the former to the latter once
trivial QIs are banned. However, we still want to check if a QI to
nsIEventTarget does something, so I added an intermediate cast up to
nsISupports, and then QI from there. I wrapped that all up in a
templated function, because the code is a bit ugly, and used it
everywhere for uniformity, even though it is not always needed.
I fixed TestCOMPtr.cpp in the same way, by casting up to nsISupports.
Differential Revision: https://phabricator.services.mozilla.com/D6855
--HG--
extra : moz-landing-system : lando
If a class A is derived from a class B, then an instance of A can be
converted to an instance of class B via a static cast, so QI is not
needed. QIs are slower than static casts.
TestCallTemplates seems to be testing that CallQueryInterface compiles
even if the first argument's class is only ambiguously castable to
nsISupports, so I changed the second argument to be a class unrelated
to the concrete class.
I also removed some useless null checks on the return value of new.
Differential Revision: https://phabricator.services.mozilla.com/D6838
--HG--
extra : moz-landing-system : lando
This adds a most recently used cache that can be used as a quick lookup table
for frequently used entries.
--HG--
extra : rebase_source : 571c32f75e985e299113f73b959809d208aad5f3
In many places, nsTArray::IndexOf is followed by accessing that element
(hopefully with `Elements() + index`, which skips unnecessary bounds checks.)
But this pattern introduces operations that could be avoided:
- IndexOf converts the address of the found element into an index,
- The caller must test for a special `NoIndex` value,
- On success, accesses convert that index back into the original address.
This patch introduces new 'ApplyIf...' functions that combine all these
operations in a more efficient ensemble: If the sought element is found, it is
passed by reference to a given callable object (usually a lambda); if not
found, another callable is invoked.
Depending on what they need, the first callable may take one of these parameter
lists: (), (size_t), (maybe-const elem_type&), (size_t, maybe-const elem_type&).
On top of removing the pointer->index->pointer operations in most cases,
invoking callables directly from ApplyIf is safer, as the array is guaranteed to
be untouched at this time.
Also, being templates taking function objects, in most cases the compiler should
be able to inline and optimize the search and its callables' code.
This patch gives example uses in nsTArray::Contains, and in
FrameProperties::GetInternal, SetInternal.
And FrameProperties::Has now calls Contains, which is more efficient because
the former code would compute an index (or NoIndex), and then convert that index
to a bool; whereas the new code directly produces a bool from within the search
algorithm.
Differential Revision: https://phabricator.services.mozilla.com/D2758
--HG--
extra : moz-landing-system : lando
This makes it much easier to update existing consumers of
XPCOMUtils.enumerateCategoryEntries to use the category manager directly.
It also, unfortunately, requires updating existing category manager consumers
to use the Services getter in order to avoid ESLint errors.
Differential Revision: https://phabricator.services.mozilla.com/D4278
--HG--
extra : rebase_source : fb9fd9b21db80af472ff6250a2e9a35e8d538147
In order to implement profile-per-install we need a mutable INI parser in early
startup. The current one is implemented in JavaScript and thus not available.
This makes the current read-only C++ INI parser mutable and removes the
JavaScript implementation.
It turns out that the two different implementations of nsIINIParserFactory and
nsIINIParser behaved slightly differently but only in ways that the single test
cared about so I've adjusted things a little to make it work.
The existing C++ implementation did not do validity checks on arguments, this
adds that making empty sections and values illegal.
Differential Revision: https://phabricator.services.mozilla.com/D3851
--HG--
rename : xpcom/tests/unit/test_iniProcessor.js => xpcom/tests/unit/test_iniParser.js
extra : source : 524941c8ed0e048ee51be1bd11082b41428ef490
extra : amend_source : 2de6cef5be97448a41733bedda29d6af34aed27a
Correctness improvements:
* UTF errors are handled safely per spec instead of dangerously truncating
strings.
* There are fewer converter implementations.
Performance improvements:
* The old code did exact buffer length math, which meant doing UTF math twice
on each input string (once for length calculation and another time for
conversion). Exact length math is more complicated when handling errors
properly, which the old code didn't do. The new code does UTF math on the
string content only once (when converting) but risks allocating more than
once. There are heuristics in place to lower the probability of
reallocation in cases where the double math avoidance isn't enough of a
saving to absorb an allocation and memcpy.
* Previously, in UTF-16 <-> UTF-8 conversions, an ASCII prefix was optimized
but a single non-ASCII code point pessimized the rest of the string. The
new code tries to get back on the fast ASCII path.
* UTF-16 to Latin1 conversion guarantees less about handling of out-of-range
input to eliminate an operation from the inner loop on x86/x86_64.
* When assigning to a pre-existing string, the new code tries to reuse the
old buffer instead of first releasing the old buffer and then allocating a
new one.
* When reallocating from the new code, the memcpy covers only the data that
is part of the logical length of the old string instead of memcpying the
whole capacity. (For old callers old excess memcpy behavior is preserved
due to bogus callers. See bug 1472113.)
* UTF-8 strings in XPConnect that are in the Latin1 range are passed to
SpiderMonkey as Latin1.
New features:
* Conversion between UTF-8 and Latin1 is added in order to enable faster
future interop between Rust code (or otherwise UTF-8-using code) and text
node and SpiderMonkey code that uses Latin1.
MozReview-Commit-ID: JaJuExfILM9
Summary:
The plan is to also expose perfecthash.py from this module on the python path.
This also allows us to stop using explicit module loading to load make_dafsa.py.
make_dafsa.py was moved into tools/ to avoid any extra python files from
accidentally ending up on the python path.
Reviewers: froydnj!
Tags: #secure-revision
Bug #: 1479484
Differential Revision: https://phabricator.services.mozilla.com/D2614
--HG--
rename : xpcom/ds/make_dafsa.py => xpcom/ds/tools/make_dafsa.py
Summary: GTest is permafailing because of this test (GTest is always running over 1200s).
Reviewers: froydnj
Reviewed By: froydnj
Bug #: 1473531
Differential Revision: https://phabricator.services.mozilla.com/D2032
--HG--
extra : rebase_source : 07413c4d7ba4eb6bd1439f292bd489a775dab61b
We're changing the counters behavior since they are not notifications anymore.
In the new behavior they don't get reset when they are retrieved,
so we can have several consumers via the promise.
If the values overflow, we let the wrapping occur (unsigned values).
MozReview-Commit-ID: 1adkszScYo4
--HG--
extra : rebase_source : cd554ad4cfa643b09f75bb07e38b5d35e08cf470
This patch is an automatic replacement of s/NS_NOTREACHED/MOZ_ASSERT_UNREACHABLE/. Reindenting long lines and whitespace fixups follow in patch 6b.
MozReview-Commit-ID: 5UQVHElSpCr
--HG--
extra : rebase_source : 4c1b2fc32b269342f07639266b64941e2270e9c4
extra : source : 907543f6eae716f23a6de52b1ffb1c82908d158a
This reduces memory usage because we only need one allocation instead of two
for the dynamic atom and its chars, and because we don't need to store a
refcount and a size. It precludes sharing of chars between dynamic atoms, but
we weren't benefiting much from that anyway.
This reduces per-process memory usage by up to several hundred KiB on my
Linux64 box.
One consequence of this change is that we need to allocate + copy in
DOMString::SetKnownLiveAtom(), which could make some things slower.
--HG--
extra : rebase_source : ba4065ea31e509dd985c003614199f73def0596c
Now uses StaticPrefs instead of DOMPrefs, and how we count dispatches for Workers.
MozReview-Commit-ID: DTumwcI5bG
--HG--
extra : rebase_source : 0cf5312e714fb260c01df647b2cd1fcc28ffc415
Valentin Gosu
Jim Blandy
Gurzau Raul
Andrea Marchesini
Mark Banner
Andrew McCreight
Henri Sivonen
Kris Maglione
Ehsan Akhgari
Coroiu Cristina
Eric Rahm
Jan de Mooij
Margareta Eliza Balazs
Gerald Squelart
Ciure Andrei
aceman
Dave Townsend
Nika Layzell
Cosmin Sabou
Calixte Denizet
Emilio Cobos Álvarez
Tarek Ziadé
Andreea Pavel
Chris Peterson
Nicholas Nethercote