This patch does the following:
1. Run the same prefixset tests when
* browser.safebrowsing.prefixset.max_array_size = 0
* browser.safebrowsing.prefixset.max_array_size = UINT32_MAX
This makes sure both of the methods to store prefixset are tested by existing testcases
2. Refine gtest with test fixture
3. Add TinySet and LargeSet testcases
Differential Revision: https://phabricator.services.mozilla.com/D30338
--HG--
extra : moz-landing-system : lando
The goal of this patch is to reduce the number of memory reallocation during
|MakePrefixSet|[1].
Here is the number of nsTArray memory reallocation occur during |MakePrefixSet|
(test in my local platform):
googpub-phish-proto: 58k times
goog-malware-proto: 9k times
goog-unwanted-proto: 25k times
goog-badbinurl-proto: 6k times
This patch improves the performance by:
1. For tables whose prefixes are less than 128*1024(malware, unwanted,
badinurl).
Store prefixes directly without dividing allocation into smaller chunks.
Because the maximum size to store all the prefixes in a single array for
these tables will be less than 512k, we can avoid Bug 1046038.
This simplifies the internal prefixset data structure generation and total
memory usage is also saved:
goog-malware-proto : 437K -> 163k
goog-unwanted-proto : 658k -> 446k
goog-badbinurl-proto: 320k -> 110k
The single largest allocated continuous memory size is:
goog-malware-proto : 86k -> 163k
goog-unwanted-proto : 86k -> 446k
goog-badbinurl-proto: 77k -> 110k
A further improvement can be done for this part is for tables with fewer
prefixes, we can use an one-dimension delta array to reduce the size of a
single continuous memory allocation.
2. For tables with more prefixes:
According to experiment, when prefixes are more than 400k
the delta arrays have very high chance that are full, in the case of
phishing table, we can estimate the capacity accurately before
applying delta algorithm.
The shortcoming of this part is when prefixes are between 130k~400k,
the capacity estimation is not accurate.
[1] https://searchfox.org/mozilla-central/rev/b2015fdd464f598d645342614593d4ebda922d95/toolkit/components/url-classifier/nsUrlClassifierPrefixSet.cpp#99
Differential Revision: https://phabricator.services.mozilla.com/D30046
--HG--
extra : moz-landing-system : lando
The checksum calculating code is used to find the root cause of a crash
bug during update(Bug 1362761). Since the algorithm will be update in
these series of patches, we don't need to keep it.
Differential Revision: https://phabricator.services.mozilla.com/D26667
--HG--
extra : moz-landing-system : lando
This is preliminary work to allowing encoding of JSCVTFP, the instruction that exists on new AArch64 devices that greatly speeds up websites that use floating-point math.
Differential Revision: https://phabricator.services.mozilla.com/D30997
--HG--
extra : moz-landing-system : lando
Due to missing class abstractions for Gecko- and non-Gecko based
browsers it's currently sub-optimal to define when preferences
as defined by tests will be set.
Given that by default we run Gecko-based applications other
browsers should opt-out from setting test preferences.
Differential Revision: https://phabricator.services.mozilla.com/D30923
--HG--
extra : moz-landing-system : lando
The patch tries to reduce the amount of initialization code
to call when creating a new Raptor class.
Initializing the ADBDevice already in the constructor of the
RaptorAndroid class is currently not possible because it would
mean that a device is immediately created but the "adb" binary
is not available for python test jobs. This has to be fixed later.
Differential Revision: https://phabricator.services.mozilla.com/D29331
--HG--
extra : moz-landing-system : lando
Though I do wonder whether we could just remove the unused data byte arg and
simplify the code...
Differential Revision: https://phabricator.services.mozilla.com/D30835
--HG--
extra : moz-landing-system : lando
Though given that getAsArray is unused and untested, maybe we should just
remove it?
Differential Revision: https://phabricator.services.mozilla.com/D30832
--HG--
extra : moz-landing-system : lando
This makes the rust toolchain artifacts contain the rust stdlib as well,
for use by searchfox. It does bring up the size of the toolchain
artifact slightly - rustc.tar.xz file for the Linux/rust 1.34 job for
example goes from 270483672 bytes to 273803148 bytes (1.23% larger) and
the equivalent android tarball goes from 230503888 to 235698736 bytes
(2.25% larger).
Differential Revision: https://phabricator.services.mozilla.com/D28282
--HG--
extra : moz-landing-system : lando
Protocols, likes about:, moz-extension, ... etc, don't have a host. Thus, an
exception will be returned if they are accessed. To avoid from that, this patch
catches this bug a try-catch.
Differential Revision: https://phabricator.services.mozilla.com/D29821
--HG--
extra : moz-landing-system : lando
Having `rustc` be `rustup`'s wrapper for `rustc` means that we may
silently honor `rustup`'s override mechanisms. We noticed this first on
OS X, where we use the "real" `cargo` but `rustup`'s `rustc` wrapper,
and problems ensued when `cargo` thought it was using one version of
`rustc`, but actually wound up using something different.
It seems better to avoid silently interposing `rustup`'s toolchain
override mechanisms everywhere, rather than having to special-case OS
X. So let's factor out a general mechanism for removing the wrappers
`rustup` provides and use that for both `rustc` and `cargo`. The tests
need adjusting because we weren't triggering the unwrapping cases
before; we don't yet test the case where we really do need to unwrap.
That test can be left for a future patch.
Differential Revision: https://phabricator.services.mozilla.com/D29531
--HG--
extra : moz-landing-system : lando
nsITaskbarTabPreview has a notxpcom method, so it has always been
treated as builtinclass. This just makes it explicit.
The same thing is true for nsIPrintSettingsWin, but as far as I can
tell it is never actually used from JS, so I just removed the
scriptable tag.
Differential Revision: https://phabricator.services.mozilla.com/D30981
--HG--
extra : moz-landing-system : lando
The second patch in bug 1518202 made it so that the reference to the
browsing context is declared to the cycle collector after all.
Differential Revision: https://phabricator.services.mozilla.com/D31001
--HG--
extra : moz-landing-system : lando
We've not been checking the clang-cl version in use. This lack of
checking is bad, for a couple of reasons:
* Released versions of clang-cl differ drastically in their robustness;
* Only the most recent version of clang-cl supports aarch64.
We should check for a minimum version of clang-cl, just like our other
supported compilers. As a bonus, we can then start depending on
features that we know appear in the particular minimum clang-cl
version. (The current patch is motivated by `/clang:` command-line
support, but one could pick other things.)
Differential Revision: https://phabricator.services.mozilla.com/D30723
--HG--
extra : moz-landing-system : lando
