Bug 1134923 removed the use of those functions in gecko, and left some
for the XPCOM standalone glue. The XPCOM standalone glue was severely
stripped down in bug 1306327, with the effect of removing the
implementation for those functions.
The remains in nsXPCOM.h are:
XPCOM_API(void*) NS_Alloc(size_t aSize);
XPCOM_API(void*) NS_Realloc(void* aPtr, size_t aSize);
XPCOM_API(void) NS_Free(void* aPtr);
With no implementation left, the first arm is never actually used, and
the second arm means every remaining use of those functions in the tree
is a macro expansion to one of moz_xmalloc, moz_xrealloc or free.
--HG--
extra : rebase_source : fd1669abc5a25d8edbd5c3a8522e22a5c3f558e2
nsEscape.cpp doesn't build in non-unified mode, as it uses mozilla::fallible,
mozilla::CheckedInt and mozilla::ASCIIMask::IsMasked without prefixing them
with the mozilla namespace. I suspect this file is usually included in
unified_cpp file which includes a "using namespace mozilla" directive.
MozReview-Commit-ID: GwlsK8kytLj
--HG--
extra : rebase_source : c3063aff7cdf10c416b8ee782c9bee745e643842
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
This Makefile.in contains a bunch of cruft for Tier-3 platforms. If
someone is still supporting any of them they can make the necessary
fixes to moz.build files themselves.
MozReview-Commit-ID: HxbbCv395Y5
--HG--
extra : rebase_source : 94f04128d2b3dd1285dfeafbfeb320b2f0d0bb19
extra : histedit_source : 2353127161ae58e54b6296e98b6b4b972ae439fe
It's easy to mess up the scoping so that (a) the label is pushed and then
immediately popped, and/or (b) the string doesn't live long enough. It's also
easy to do a utf16-to-utf8 conversion unnecessarily when the profiler is
inactive.
This patch splits that macro into three new ones that are harder to mess up.
- AUTO_PROFILER_LABEL_DYNAMIC_CSTR: same as current.
- AUTO_PROFILER_LABEL_DYNAMIC_NSCSTRING: for nsCStrings.
- AUTO_PROFILER_LABEL_DYNAMIC_LOSSY_NSSTRING: for nsStrings.
--HG--
extra : rebase_source : 53c8b43b6a1be06d00618a133e28bf95c46a3ba3
It's easy to mess up the scoping so that (a) the label is pushed and then
immediately popped, and/or (b) the string doesn't live long enough. It's also
easy to do a utf16-to-utf8 conversion unnecessarily when the profiler is
inactive.
This patch splits that macro into three new ones that are harder to mess up.
- AUTO_PROFILER_LABEL_DYNAMIC_CSTR: same as current.
- AUTO_PROFILER_LABEL_DYNAMIC_NSCSTRING: for nsCStrings.
- AUTO_PROFILER_LABEL_DYNAMIC_LOSSY_NSSTRING: for nsStrings.
--HG--
extra : rebase_source : 59f77df0124249bfd11fee3585420a17b4201d37
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.
(Path is actually r=froydnj.)
Bug 1400459 devirtualized nsIAtom so that it is no longer a subclass of
nsISupports. This means that nsAtom is now a better name for it than nsIAtom.
MozReview-Commit-ID: 91U22X2NydP
--HG--
rename : xpcom/ds/nsIAtom.h => xpcom/ds/nsAtom.h
extra : rebase_source : ac3e904a21b8b48e74534fff964f1623ee937c67
Adds a new directory provider key "XRESysExtDev" to be used by system extension
developers needing to load system extensions from a directory readable by
sandboxed content processes.
MozReview-Commit-ID: 4BKOZoPzCC3
--HG--
extra : rebase_source : 452db8d53a1f0248a080f858c48492978b5db808
Removes the XPCOM interface for nsIDOMHTMLCanvasElement, replacing it
with binding class usage.
MozReview-Commit-ID: DQJhqGlY8U6
--HG--
extra : rebase_source : a33146a22ee356a0840bb9fef82d51b2b315f6d7
The Windows and OSX code paths were essentially doing the same thing,
and the Unix fallback was using an old convention that is pretty much
outdated.
Under normal conditions (XPCOM initialized by Firefox),
NS_XPCOM_INIT_CURRENT_PROCESS_DIR is set from BinaryPath anyways, so
this only really affects adhoc XPCOM initialization from e.g. C++ unit
tests.
--HG--
extra : rebase_source : b3151fffd4c82159b633a48dead86f2c3b0a03d6
Back in the day, there was no global with an already initialized
DirectoryService. But now there is, and, in fact,
GetCurrentProcessDirectory already errors out if that global is not set
by the time it's called. All calling nsDirectoryService::Create achieves
is doing the check again and calling QueryInterface, which we don't need
to do anyways.
--HG--
extra : rebase_source : 32f5080ecb8165cffd601799e72d278b482b0871
It seemingly hasn't been needed since Mac OS 10.7. A diagnostic assertion that
has been in place for a while hasn't caught any uses of it.
--HG--
extra : rebase_source : 9834849eec9174267c7df8de7fd22840ffa36d8f
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
Add macro for nsISupports inheriting classes that need cycle
collection and only inherit from one parent, with no interface table
needed. Takes care of map and addref/release calls.
MozReview-Commit-ID: LtTwYH0DeEz
--HG--
extra : rebase_source : d3650209ddd7e28cbf205ac84f152b9763c26bde
This fixes the build in non-unified mode, as nsCOMArray::Sort() method uses
NS_QuickSort().
MozReview-Commit-ID: CDBLIX8D3mL
--HG--
extra : rebase_source : 67902cf10b9311adbd97fecf7906762bb86c52e4
The Windows and OSX code paths were essentially doing the same thing,
and the Unix fallback was using an old convention that is pretty much
outdated.
Under normal conditions (XPCOM initialized by Firefox),
NS_XPCOM_INIT_CURRENT_PROCESS_DIR is set from BinaryPath anyways, so
this only really affects adhoc XPCOM initialization from e.g. C++ unit
tests.
--HG--
extra : rebase_source : f7faa6f22ffc56fb4da7ae96eb571a35fa6f615d
Back in the day, there was no global with an already initialized
DirectoryService. But now there is, and, in fact,
GetCurrentProcessDirectory already errors out if that global is not set
by the time it's called. All calling nsDirectoryService::Create achieves
is doing the check again and calling QueryInterface, which we don't need
to do anyways.
--HG--
extra : rebase_source : 519980829be4ff4a0941c0e8d18be5761ece6552
(patch is actually r=erahm,mystor)
nsTFixedString<T> is only used as a base class for nsTAutoStringN<T, N>, so
this patch merges the former into the latter, cutting some code and simplifying
the string class hierarchy.
Because the "Fixed" name is now gone, the patch also renames
StringDataFlags::FIXED as INLINE and ClassDataFlags::FIXED as INLINE.
The patch also removes nsFixed[C]String and ns_auto_[c]string! from Rust code
because nsAutoString can't be implemented directly in Rust due to its move
semantics. There were only two uses of ns_auto_string! outside of tests so this
seems like a minor loss.
MozReview-Commit-ID: 8ntximghiut
--HG--
extra : rebase_source : f36edbae0553adcfee356fb8b311097ff7424786
The Windows and OSX code paths were essentially doing the same thing,
and the Unix fallback was using an old convention that is pretty much
outdated.
Under normal conditions (XPCOM initialized by Firefox),
NS_XPCOM_INIT_CURRENT_PROCESS_DIR is set from BinaryPath anyways, so
this only really affects adhoc XPCOM initialization from e.g. C++ unit
tests.
--HG--
extra : rebase_source : b3151fffd4c82159b633a48dead86f2c3b0a03d6
Back in the day, there was no global with an already initialized
DirectoryService. But now there is, and, in fact,
GetCurrentProcessDirectory already errors out if that global is not set
by the time it's called. All calling nsDirectoryService::Create achieves
is doing the check again and calling QueryInterface, which we don't need
to do anyways.
--HG--
extra : rebase_source : 32f5080ecb8165cffd601799e72d278b482b0871
Removes the XPCOM interface for nsIDOMHTMLAreaElement, replacing it
with binding class usage.
MozReview-Commit-ID: IaX4JFTPZn6
--HG--
extra : rebase_source : 79f9200c6ff9e081a5d9bc21eaa605f88caa99e9
This patch merges nsAtom into nsIAtom. For the moment, both names can be used
interchangeably due to a typedef. The patch also devirtualizes nsIAtom, by
making it not inherit from nsISupports, removing NS_DECL_NSIATOM, and dropping
the use of NS_IMETHOD_. It also removes nsIAtom's IIDs.
These changes trigger knock-on changes throughout the codebase, changing the
types of lots of things as follows.
- nsCOMPtr<nsIAtom> --> RefPtr<nsIAtom>
- nsCOMArray<nsIAtom> --> nsTArray<RefPtr<nsIAtom>>
- Count() --> Length()
- ObjectAt() --> ElementAt()
- AppendObject() --> AppendElement()
- RemoveObjectAt() --> RemoveElementAt()
- ns*Hashtable<nsISupportsHashKey, ...> -->
ns*Hashtable<nsRefPtrHashKey<nsIAtom>, ...>
- nsInterfaceHashtable<T, nsIAtom> --> nsRefPtrHashtable<T, nsIAtom>
- This requires adding a Get() method to nsRefPtrHashtable that it lacks but
nsInterfaceHashtable has.
- nsCOMPtr<nsIMutableArray> --> nsTArray<RefPtr<nsIAtom>>
- nsArrayBase::Create() --> nsTArray()
- GetLength() --> Length()
- do_QueryElementAt() --> operator[]
The patch also has some changes to Rust code that manipulates nsIAtom.
MozReview-Commit-ID: DykOl8aEnUJ
--HG--
extra : rebase_source : 254404e318e94b4c93ec8d4081ff0f0fda8aa7d1
nsHtml5Atoms are very similar to dynamic nsAtoms. This patch removes the former
in favour of the latter, which leaves nsAtom as the only subclass of nsIAtom.
nsAtom::mKind is still used to distinguish dynamic atoms from HTML5 atoms, and
the HTML5 parser still uses manual memory management to handle its HTML5 atoms.
nsHtml5AtomEntry::mAtom had to be changed from an nsAutoPtr to a raw pointer
because nsAtom's destructor is private.
MozReview-Commit-ID: 1pBzwkog3ut
--HG--
extra : rebase_source : fbb819e527cb30606348da9ce3eede62e00fb936
This patch moves nsAtom's declaration to nsIAtom.h. In order to keep most of
nsAtom's members private the patch also does the following.
- It introduces a new class, nsAtomFriend, which encapsulates the functions
that will need access to nsAtom's private members.
- It moves GCKind, GCAtomTable(), and GCAtomTableLocked() out of nsAtom.
- It removes the factory methods, and replaces their uses with direct
constructor calls.
MozReview-Commit-ID: L8vfrHsR2cS
--HG--
extra : rebase_source : d38a65515ae82c355966ca80ab235bea11b638af
Because it's going to be exposed via nsIAtom.h in the next few patches.
MozReview-Commit-ID: A81s1nWrvmB
--HG--
extra : rebase_source : 43990feb460fc7343c994f72fb6c6679a3aeb1cc
Full specialization is allowed in MSVC, but not in gcc.
MozReview-Commit-ID: 9QI6YWc5Rvr
--HG--
extra : rebase_source : 7387899a6d76832afbe15e088b80a82adee59ca3
The NS_LITERAL_CSTRING macro creates a temporary nsLiteralCString to encapsulate the string literal and its length, but AssignLiteral() can determine the string literal's length at compile-time without nsLiteralCString.
MozReview-Commit-ID: B5Y8KyExPQ8
--HG--
extra : rebase_source : e27b266c145daa5acd887e998c6d5b408101e1db
extra : source : 33f49977a33cbdb1c7127871b940eefccc018f65
Removes the nsIDOMHTMLObjectElement XPCOM interface, replacing it with
HTMLObjectElement and FromContent conversion usage.
MozReview-Commit-ID: dmsjSO97uh
--HG--
extra : rebase_source : 9b2c25b8681f754bc34233afccdb6fc5d38f0804
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
This patch reduces sizeof(PLDHashTable) as follows.
- 64-bit: from 40 bytes to 32
- 32-bit: from 28 bytes to 20
It does this by doing the following.
- It moves mGeneration from EntryStore to PLDHashTable, to avoid unnecessary
padding on 64-bit. This requires tweaking EntryStore::Set() as explained in a
comment.
- It also shrinks mGeneration from uint32_t to uint16_t, saving 2 bytes of
data.
- It shrinks mEntrySize from uint32_t to uint8_t, to cut 3 bytes of data.
- It shrinks mHashShift from int16_t to uint8_t, trimming another byte of data,
and moves it, saving another 2 bytes of padding.
And it reorders the fields so the word-sized ones are at the start, which makes
it easier to imagine the memory layout.
The patch also adds a test, and fixes some misordered function arguments in
existing tests.
--HG--
extra : rebase_source : 6ed6f7be68477fd4a82f07dd2f51c1f1d9b92dcc
The current code replaces one PLDHashTable's mGeneration with another. If the
two generation values happen to be equal, it will look as though the storage
hasn't changed when really it has.
The fix is to use EntryStore::Set() to update mEntryStore, which increments
mGeneration appropriately.
--HG--
extra : rebase_source : d1779a143746c8d1a3e67bc3685e703496206b0f
nsIHandleReportCallback, typedef of nsIMemoryReporterCallback, has been the
preferred name for a long time and is used in most places. This patch removes
nsIMemoryReporterCallback.
--HG--
extra : rebase_source : c675076b4f98d93d96235dad890e31e0b0e6c277
Bug 1388789 introduced a bug breaking formats like "%*.f". The problem
was that the next "natural" argument was taken before the "*" width
argument.
MozReview-Commit-ID: BZack9faY7a
--HG--
extra : rebase_source : a14485914ef9e29e38f29be6c1df1372ce5e722f
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.
nsTextFormatter unconditionally emitted a trailing \0, leading some code
elsewhere to have to work around this. This changes the code to only
emit it in snprintf.
MozReview-Commit-ID: G3CBpAPp9Tn
--HG--
extra : rebase_source : 36666476a4f796e2553c9fa31daa54d245ae3b5f
The char* and char16_t* cases handled null strings differently;
normalize them to both emit "(null)".
MozReview-Commit-ID: IzRkc3pSSjl
--HG--
extra : rebase_source : f43a1a852a2c8aa3d6607c7202f7cd42fdd5740a
Change nsTextFormatter functions to template functions, box their
arguments, and then make the formatter mostly impervious to type
mismatches. Most formatting is done according to the type of the actual
argument.
MozReview-Commit-ID: H8WmyxFCb7s
--HG--
extra : rebase_source : ad98ad6243825f1a892fc6a641d155e239b12a6b
nsTextFormatter::vsnprintf is defined to return uint32_t(-1) on error.
However, it was not doing this.
nsTextFormatter::vssprintf is defined as infallible; enforce this by
having it return void.
MozReview-Commit-ID: LdOhIHzRvAT
--HG--
extra : rebase_source : 7164eb47a89ecebfa50d40684eea1325de0172ba
nsTextFormatter tried to pass unrecognized escapes in the format string
through to the output. However, if the format held a width or
precision, that text was not output. It seems better to me to try to
preserve the format text as-is.
MozReview-Commit-ID: HoBykpfzK7C
--HG--
extra : rebase_source : 9b071db3800e3e75cabb4995a920818dfb35b03d
nsTextFormatter used nsAutoString for arrays of hex digits; but this
didn't seem to provide any benefit.
MozReview-Commit-ID: EYHtnAzJL8h
--HG--
extra : rebase_source : 6906075f06478b7c10229201de46e36d08d1f7f8
The runtime type-checking rewrite of nsTextFormatter will not support
va_list uses. So, make these functions private and fix the sole user.
MozReview-Commit-ID: IBWALVzIcHC
--HG--
extra : rebase_source : a822697c81c1a054359fc2ecd894d51f95686548
This is a preexisting issue that makes nsMultiplexInputStream multiple-inherit
from nsIInputStream: once via nsIMultipartInputStream and once via
nsIAsyncInputStream. This causes problems once we end up with more multiplex
streams that are async streams, because then some assingments to
nsCOMPtr<nsIInputStream> start asserting. This patch just removes the footgun
by getting rid of the multiple inheritance.
This is a preexisting issue that makes nsMultiplexInputStream multiple-inherit
from nsIInputStream: once via nsIMultipartInputStream and once via
nsIAsyncInputStream. This causes problems once we end up with more multiplex
streams that are async streams, because then some assingments to
nsCOMPtr<nsIInputStream> start asserting. This patch just removes the footgun
by getting rid of the multiple inheritance.
The compiler complains because a postfix increment is done inside of an assert.
MozReview-Commit-ID: LSRsWMn9Tlj
--HG--
extra : rebase_source : 18539a430c3d84675c602699be9a5a62dd477fec
There is no use mozilla namespace statement in this compilation unit, so the
call to GetErrorName() has to be prefixed with the mozilla namespace.
MozReview-Commit-ID: G3caP2v9PFF
--HG--
extra : rebase_source : 9aebe0711cf8ad81dc47592521a4f29b4f75caab
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
The template declaration and definition of Compare use NS_FASTCALL,
while the explicit instantiation of Compare does not, which produces
complaints from newer compilers. Add NS_FASTCALL to the explicit
instantiation so that things match up.
We're calling GetCurrentVirtualThread() which is defined in nsThreadUtils.h, so
without including nsThreadUtils.h we'll get a compile error if unified builds
are disabled.
MozReview-Commit-ID: JWCigMqNJDi
--HG--
extra : rebase_source : bac48b8f91e6561dfb7afe2828c3652431347c40
nsTSubstring.cpp is calling RoundUpPow2 which is defined in MathAlgorithms.h.
Without this, we get a build failure in non-unified builds.
MozReview-Commit-ID: Dz7VIZk4dLw
--HG--
extra : rebase_source : 7795784894bfca6e921d38cedaa4f543317c2165
This patch skips test_nsIProcess.js when it is running on linux64-ccov.
MozReview-Commit-ID: EZaAcKsy0UA
--HG--
extra : transplant_source : %DD%05C%CD3h%95e%B9%05%F8%7C%D8ZWOh%DBj%CA
Free dirty pages appear as "page-cache" in about:memory reports, but
when minimizing memory, and more generally, on memory pressure, they're
currently not force-free()ed on desktop, while they are on mobile.
There doesn't seem to be much reason not to do it on desktop as well,
and it should help reduce the noise in "explicit" allocations measurements
on CI, too.
--HG--
extra : rebase_source : e477532dda5e72eb8797b5bcdc9060ca46106275
This removes the double-include macro hackery that we use to define two
separate string types (nsAString and nsACString) in favor of a templated
solution.
Annotations for Valgrind and the JS hazard analysis are updated as well as
the rust binding generations for string code.
--HG--
extra : rebase_source : 63ab2c4620cfcd4b764d42d654c82f30f984d016
extra : source : 9115364cd4aa078c49bba7911069f8178e55166f
This fixes improper usages of Find where an offset was actually being use for
the boolean ignore case flag. It also fixes a few instances of passing in a
literal wchar_t to our functions where a NS_LITERAL_STRING or char16_t should
be used instead.
--HG--
extra : rebase_source : 5de1e9335895d65e6db06c510e8887d27be3390f
extra : source : f762f605dd83fc6331161a33e1ef5d54cafbd08d
ISO C++ forbids converting a string constant to 'wchar_t*' [-Werror=write-strings]
Either change it to a nullptr (which has same intent) or pass through a static
MozReview-Commit-ID: CSunOCyO9PN
--HG--
extra : rebase_source : bfdabc1f463eca75987c6561f7c3ea60acf0340f
Now that nsIAtom is non-scriptable, a .idl file isn't needed.
I made the new nsIAtom.h file by starting with a generated nsIAtom.h file, and
then cleaning it up and removing some stuff that wasn't necessary.
--HG--
extra : rebase_source : 9655fd38984512bd96cf5555048f7774414f6d92
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
These methods return an addrefed raw pointer, which makes them easy to use in
ways that cause leaks. If they're to continue returning an addrefed pointer,
they should explicitly return an already_AddRefed.
This also switches to StaticRefPtr with ClearOnShutdown for the cached
pointers for the sake of sanity.
MozReview-Commit-ID: D0lDpU8Hqug
--HG--
extra : rebase_source : 7b199070805fc0472eaf8409932517700ed23d49
NS_GetWeakReference, called from do_GetWeakReference, QI's its argument
to nsISupportsWeakReference to determine whether a weak reference can be
obtained. If NS_GetWeakReference is already receiving a
nsISupportsWeakReference pointer, or something than can be converted to
one, then we can skip the QI for a small performance win.
QIing to CC interfaces shows up in Speedometer profiles for a few
classes. Presumably there are many of these objects being created and
destroyed. By making these classes check first for the CC interfaces
directly, rather than going up the inheritance chain, this overhead
should be reduced.
MozReview-Commit-ID: I3sf3my8oua
--HG--
extra : rebase_source : f08884a944d5b4ed1eb1da1070de64f21fc9868a
The main purpose of defining this is to make conversion of places that
use the non-CC variant easier. There are many more places that could
be converted to use these new macros, if somebody felt motivated.
MozReview-Commit-ID: HspjcN76fjg
--HG--
extra : rebase_source : bf3baa586f90f0afbe9229c32d38cb34cc909b9b
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.
--HG--
extra : histedit_source : 4ba3ee62fd2871a87970faca8a70b2284e83981d%2C9246ac39cea50c3bb0d1693d8e831c3b3ad33ad9
After all the previous work, we can now base64 decode nsString types
without intermediate conversion steps to nsCString, which is faster and
more memory-efficient.
The current nsString decoding routine indirectly relies on the various
checks this routine performs; making it generic over string types
ensures that we can eventually call it directly from the nsString
decoding routine.
The existing Base64URL code converts from `const char` to `uint8_t`.
We're going to want versions that convert from character types to
character types, so make the decode routines accept generic input and
output types.
The decoding logic is the same for Base64 and Base64URL; we might as
well reuse the routines that we already have for Base64URL decoding so
we don't make mistakes in the logic.
These tables are nearly identical to the ones for base64url decoding,
but ideally will be slightly more readable, since things are broken up
into sets of eight entries at a time.
After all the previous work, we can base64 encoding nsString values
directly into nsString values, without having to go through intermediate
nsCString values. Since this routine backs base64 routines exposed to
the web, this change should help with OOMs that we see associated with
base64 encoding.
The nsACString -> nsACString encode routine has several checks in it for
correct operation, and the nsAString -> nsAString encode routine relies
on those checks happening via the nsACString -> nsACString routine.
Once we start encoding nsAStrings directly, we'll still need those
checks, and the easiest way to ensure they happen is to move the core
base64 encode logic for strings into a templated helper.
One less use of NSPR is a good thing. The failure cases that
PL_Base64Encode would have caught for us are:
1. "Truncation".
2. Integer overflow when computing destination string length.
3. Malloc failures.
The first one only gets checked if we pass in zero for the source
length, which we never do. The latter two only get checked if we pass
in a null pointer for the destination, which we never do. So removing
the error handling PL_Base64Encode implies here is a good thing.
Its return value is never used, and most implementations return nullptr anyway.
MozReview-Commit-ID: 8rxC053mmE8
--HG--
extra : rebase_source : 61a0b8b1373396182efd27d3c01b96e5e5541364
This removes the double-include macro hackery that we use to define two
separate string types (nsAString and nsACString) in favor of a templated
solution.
Annotations for Valgrind and the JS hazard analysis are updated as well as
the rust binding generations for string code.
This fixes improper usages of Find where an offset was actually being use for
the boolean ignore case flag. It also fixes a few instances of passing in a
literal wchar_t to our functions where a NS_LITERAL_STRING or char16_t should
be used instead.
We now have jemalloc_ptr_info() and moz_malloc_enclosing_size_of(), which can
be used to measure heap blocks via interior pointers. This patch does the
following.
- Adds MOZ_DEFINE_MALLOC_ENCLOSING_SIZE_OF, for defining
measure-via-interior-pointer functions.
- Uses these functions to replace some horrid pointer arithmetic in functions
measuring Rust types.
--HG--
extra : rebase_source : 5128408256c128222025153ae3e0f924b2499a2a
Also adds a mozilla/ResultExtensions.h header to define the appropriate
conversion functions for nsresult and PRResult. This is in a separate header
since those types are not available in Spidermonkey, and this is the pattern
other *Extensions.h headers follow.
Also removes equivalent NS_TRY macros and WrapNSResult inlines that served the
same purpose in existing code, and are no longer necessary.
MozReview-Commit-ID: A85PCAeyWhx
--HG--
extra : rebase_source : a5988ff770888f901dd0798e7717bcf6254460cd
This allows MOZ_TRY and MOZ_TRY_VAR to be transparently used in XPCOM methods
when compatible Result types are used.
Also removes a compatibility macro in SimpleChannel.cpp, and an identical
specialization in AddonManagerStartup, which are no longer necessary after
this change.
MozReview-Commit-ID: 94iNrPDJEnN
--HG--
extra : rebase_source : 24ad4a54cbd170eb04ded21794530e56b1dfbd82
When used as an error value, nsresult should never be NS_OK, which means that
we should be able to safely pack simple nsresult Result values into a single
word.
MozReview-Commit-ID: GJvnyTPjynk
--HG--
extra : rebase_source : ab5a64b545dfbfe9bbef167f8b63ecbf00b16e07