nsXPIDLStrings are marked as VOIDED upon initialization. Most of these local
nsXPIDLString variables are immediately set via getter_Copies(), which will
either assign a string value (using Adopt()) or do SetIsVoid(). These can be
trivially converted to nsString, which will get the same treatment.
The patch suitably converts the remaining nsXPIDLString local variable as well.
--HG--
extra : rebase_source : 5fff9f2c6844559198f601853f8db08564add7d5
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
Checking this pref to avoid log spam in opt builds, in sandboxes, JS
components, and whatever uses nsFrameMessageManager's dump method.
This does mean that on Windows in an opt build when a debugger is
present a debug string will no longer be printed unless the pref is
set, but I think that is consistent with the non-Windows behavior.
MozReview-Commit-ID: FWLAzBRVhlx
--HG--
extra : rebase_source : cc5669f422729788f1ebc300d4450290913a3055
We should turn on test_localeCompare.js again on Android since we use ICU.
MozReview-Commit-ID: 1H0DsKpWkId
--HG--
extra : rebase_source : d29564bfd20ee6fbc2eadf2f4b80066efc3deef0
extra : histedit_source : 294c17ea1736f196aca7aa969203428e6792625e
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
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 patch replaces four functions of the name AssignWithConversion which
are essentially wrappers around CopyASCIItoUTF16 and LossyCopyUTF16toASCII
with direct calls to the latter two functions. The replaced functions are:
void nsCString::AssignWithConversion( const nsAString& aData )
void nsString::AssignWithConversion( const nsACString& aData )
void nsTString_CharT::AssignWithConversion(
const incompatible_char_type* aData,
int32_t aLength = -1);
The last of the three exists inside the double-included nsTString* world and
so describes two functions, giving four in total.
This has two advantages:
* it removes code
* at the call points, it makes clear (from the replacement name) which
conversion is being carried out. The generic name "AssignWithConversion"
doesn't make that obvious -- one had to infer it from the types.
The patch also removes two commented out lines from
editor/composer/nsComposerCommands.cpp, that appear to be related. They are
at top level, where they would never have compiled. They look like
leftovers from some previous change.
--HG--
extra : rebase_source : fb47bf450771c3c9ee3341dd14520f5da69ec4f5
We have a minimum requirement of VS 2015 for Windows builds, which supports
the z length modifier for format specifiers. So we don't need SizePrintfMacros.h
any more, and can just use %zu and friends directly everywhere.
MozReview-Commit-ID: 6s78RvPFMzv
--HG--
extra : rebase_source : 009ea39eb4dac1c927aa03e4f97d8ab673de8a0e
Off-thread parse tasks depend on the memory allocated by the main-thread
script preloader, so that memory needs to be kept alive until they finish. In
normal use cases, this is guaranteed, but when the browser shuts down very
quickly (as sometimes happens in tests), or we invalidate the startup caches
in the middle of the startup process, they can sometimes be freed too early.
MozReview-Commit-ID: GQmkVbWgTH9
--HG--
extra : rebase_source : 523fb559f3d71f16be11ae275ab1f6ea3900eff8
In general, we always want to compile with lazy source whenever we intend to
store code in the startup bytecode cache. Currently, we only do so when the
main StartupCache is available (which is only in the parent process), even if
we'll be storing code in the ScriptPreloader cache.
The main side-effect of this is that scripts which are used in a content
process do not use lazy source, but *do* use lazy parsing. And since we need
to clone pre-loaded scripts into their target compartment before executing, we
end up eagerly compiling those lazy functions on the main thread as soon as we
execute the script, in order to clone them. And this causes two side-effects
of its own:
1) It's terrible for startup performance.
2) It creates new scope chains which didn't exist when the clone began, and
which are likely responsible for bug 1367896.
MozReview-Commit-ID: 6lZLb68zitp
--HG--
extra : rebase_source : 2f2bc11d0123fd7e14c2a5e716a764e7ab8ded46
Because it's just a wrapper for js_free().
Furthermore, JS_smprintf() and friends return a JS::UniqueChars, which is also
wired up to free with js_free(). So having the indirection via
JS_smprintf_free() obfuscates things.
--HG--
extra : rebase_source : 1db80199dc801a2684fffe2a5fd5349a42c6941b
Using the unmolested module location string as the cache key removes a huge
chunk of overhead when loading cached modules.
This also ensures that multiple URLs are not used to load the same module,
which would result in it being loaded more than once in the new regime
MozReview-Commit-ID: BAWoOJQSTc1
--HG--
extra : rebase_source : e5b295a498caf76e60efec4d174e558e9e55d77b
extra : histedit_source : dd683966b30090b5702264c2903e6050be0e4137
Since we now usually load modules from one of the startup caches, we usually
have no need to ever actually create a channel in order to load them.
Resolving the URIs directly is much cheaper in the normal case.
MozReview-Commit-ID: 8W8RMHRnyBa
--HG--
extra : rebase_source : 073ae92c3dc53e86084c1daa1ccfe720ade634c6
extra : histedit_source : cf6cc2b025a839e39aa48bf412ee3a273b549bbe
The Chromium IPC histogram code used the StatisticsRecorder object for storage.
This is keyed by histogram name, which doesn't match our storage reality anymore.
Instead we use a name to refer to a set of histogram instances that record data from different processes, as well as separating session and subsession data.
Consequently we need to rewrite this storage, which means StatisticsRecorder is not used anymore.
MozReview-Commit-ID: 1LC7YubpKaD
XPCOMUtils.generateQI is called a lot, and the current implementation is
especially inefficient. It relies on calling the stringification slow path
twice for each interface ID, which begins to add up fast given how often it's
called.
MozReview-Commit-ID: 2O87wBVMA2G
--HG--
extra : rebase_source : b3d43fbe77990e82702491a58d59c4e439d3d2f8
Kris Maglione
Bobby Holley
Nicholas Nethercote
Jason Orendorff
Henry Chang
Masatoshi Kimura
Andrew McCreight
Makoto Kato
Jim Blandy
Till Schneidereit
Marco Castelluccio
Sebastian Hengst
Carsten "Tomcat" Book
Sylvestre Ledru
Julian Seward
Bevis Tseng
Kartikaya Gupta
Olli Pettay
Yoshi Huang
Georg Fritzsche
Florian Quèze
Wes Kocher
Brian Hackett
Christoph Kerschbaumer