image.mem.volatile.min_threshold_kb is the minimum buffer allocation for
an image frame in KB before it will use volatile memory. If it is less
than it will use the heap. This only is set to > 0 on Android.
image.mem.animated.use_heap forces image frames to use the heap if it is
for an animated image. This is only enabled for Android, and was
previously a compile time option also for Android.
"Include what you use."
--HG--
extra : rebase_source : 2239a380029e0efbc9dd3042459222a67c38d70f
extra : amend_source : 4453c32cc469caa592049167205666997f1a1e7b
extra : histedit_source : a533edd4a4d3d0642b08989e93674661d27baa6a%2C37d27eeef9580381ccc0de8507f60166dabf1730
We instead add a templated method NS_MutatorMethod that returns a std::function<nsresult(nsIURIMutator*)> which Apply then calls with mMutator as an argument.
The function returned by NS_MutatorMethod performs a QueryInterface, then calls the passed method with arguments on the result.
MozReview-Commit-ID: Jjqp7gGLG1D
--HG--
extra : rebase_source : f2a17aee7bb66a7ba8652817d43b9aa7ec7ef710
We instead add a templated method NS_MutatorMethod that returns a std::function<nsresult(nsIURIMutator*)> which Apply then calls with mMutator as an argument.
The function returned by NS_MutatorMethod performs a QueryInterface, then calls the passed method with arguments on the result.
MozReview-Commit-ID: Jjqp7gGLG1D
--HG--
extra : rebase_source : 592d13349a8c4627c7ce3146ec592f577b39f3cc
This was first suggested 17 years ago!
The error recovery works by just scanning forward for the next ';' token.
This change allows a lot of the gtest tests to be combined.
MozReview-Commit-ID: CbZ2OFtdIxf
--HG--
extra : rebase_source : 5a43fff06e88b45a095725856bbe1e6b5470c9a0
The image decoding thread pool can grow to be quite large, up to 32
threads, depending on the number of processors on the system. If the
user is not actively browsing, these threads are occupying resources
which could be reused elsewhere. After the timeout period, it will
release up to half of the threads in the pool.
The meaning of "possibly-changed" is provided by the big comment above
MustSendToContentProcesses.
On a new profile this reduces the number of prefs sent like so:
- Command-line: 222 --> 3
- IPC: 3129 --> 130
On an older profile:
- Command-line: 222 --> 3
- IPC: 3165 --> 180
MozReview-Commit-ID: DcgedhXhZd8
--HG--
extra : rebase_source : acef424fab5031347cbcbd5c3e6a24ee66895ef9
No Nightly testers don't report new compatibility issue. Additionally, if we
make Firefox use <div> as defaultParagraphSeparator in release build, web
services may stop supporting our current behavior quickly because they can
get rid of hack for us. Therefore, we should do this in the cycle of Gecko 60
which is next ESR. If we did this later, ESR users may have become not to be
able to use existing web services suddenly immediately after we did this in 61
or 62. We should avoid this bad scenario.
MozReview-Commit-ID: 7Um79Ky7n8i
--HG--
extra : rebase_source : 45c6d521ddc1166decb60cc8437ffb703b1e9aff
This has two advantages. First, it reduces memory usage, as per the following
calculation.
64-bit:
- Old sizes:
- sizeof(Pref) = 32
- New sizes:
- sizeof(PrefEntry) = 16
- sizeof(Pref) = 32
- Change:
- -16 per empty slot in the hash table
- +16 per used slot
- A win if less than half the table slots are used
32-bit
- Old sizes:
- sizeof(Pref) = 20
- New sizes:
- sizeof(PrefEntry) = 8
- sizeof(Pref) = 16
- Change:
- -12 per empty slot in the hash table
- +4 per used slot in the hash table
- A win if table is < 75% full
Table size:
- The table is currently less than half full: ~3100 used out of 8192 slots.
- The table is always <= 75% full, because that's the max load factor (for
non-gigantic tables).
- Therefore it's a win for both cases.
Old sizes, chrome process, 64-bit:
> 718,712 B (00.36%) -- preferences
> +--262,176 B (00.13%) -- hash-table
> +--197,384 B (00.10%) -- callbacks
> +--114,688 B (00.06%) -- pref-name-arena
> +---92,240 B (00.05%) -- root-branches
> +---30,456 B (00.02%) -- string-values
> +---21,688 B (00.01%) -- cache-data
> +-------80 B (00.00%) -- misc
New sizes, chrome process, 64-bit:
> 672,568 B (00.41%) -- preferences
> +--181,160 B (00.11%) -- callbacks
> +--131,104 B (00.08%) -- hash-table # smaller
> +--114,688 B (00.07%) -- pref-name-arena
> +--101,152 B (00.06%) -- pref-values # new
> +---92,240 B (00.06%) -- root-branches
> +---30,456 B (00.02%) -- string-values
> +---21,688 B (00.01%) -- cache-data
> +-------80 B (00.00%) -- misc
Old sizes, smallest content process, 64-bit:
> 500,712 B (02.89%) -- preferences
> +--262,176 B (01.51%) -- hash-table
> +--114,688 B (00.66%) -- pref-name-arena
> +---62,520 B (00.36%) -- callbacks
> +---30,456 B (00.18%) -- string-values
> +---17,832 B (00.10%) -- cache-data
> +---12,960 B (00.07%) -- root-branches
> +-------80 B (00.00%) -- misc
New sizes, smallest content process, 64-bit:
> 470,792 B (02.70%) -- preferences
> +--131,104 B (00.75%) -- hash-table # smaller
> +--114,688 B (00.66%) -- pref-name-arena
> +--101,152 B (00.58%) -- pref-values # new
> +---62,520 B (00.36%) -- callbacks
> +---30,456 B (00.17%) -- string-values
> +---17,832 B (00.10%) -- cache-data
> +---12,960 B (00.07%) -- root-branches
> +-------80 B (00.00%) -- misc
The "hash-table" values drop by more than the size of the new "pref-values"
value.
On 64-bit, this reduces memory usage per process by 30--40 KB. On 32-bit, the
number is slightly more.
The second major advantage of this change is flexibility -- it opens up the
possibility of different Pref objects being stored in different way. For
example, static Prefs could be stared statically, letting them be shared
between processes so long as they don't change (see bug 1437168).
MozReview-Commit-ID: KmgbJaoOQ1J
--HG--
extra : rebase_source : 9f8201583432c1414ab3e17e80fe23a369ac264b
This feature is confusing for Nightly users in its current state, and the
suggested websites, in foreign languages, may look worrisome to some.
Bug 1340663 must figure out these issues before re-enabling the feature.
MozReview-Commit-ID: 6RJ0Ff1B3AJ
--HG--
extra : rebase_source : 569b5ae833c4f5c05656522d0d9d0ad00679c370
This construct is nicer than NS_INTERFACE_MAP_BEGIN and assures the
reader there's no weirdness in the QI implementation. This change does
mean that PGO doesn't get an opportunity to measure the frequency of
which interfaces are QI'd most often. I think this is probably an OK
tradeoff to make, given the prevalence of NS_IMPL_QUERY_INTERFACE
elsewhere in the codebase.
The one thing we have to ensure with this change is that the ambiguous
QI to nsISupports uses the proper class after the change. The
NS_IMPL_QUERY_INTERFACE macro chooses the first interface listed to
disambiguate the cast to nsISupports.
The image decoding thread pool can grow to be quite large, up to 32
threads, depending on the number of processors on the system. If the
user is not actively browsing, these threads are occupying resources
which could be reused elsewhere. After the timeout period, it will
release up to half of the threads in the pool.
This lets us have a proper constructor for Pref, which is nice.
The patch also adds a missing case to PrefTypeToString(), and reorders the
fields in Pref to be more sensible.
MozReview-Commit-ID: A01ULF4q08O
--HG--
extra : rebase_source : 835e494ad18e3ea4de9f02beca8266551bfffe5e
Csoregi Natalia
Sebastian Hengst
Eric Rahm
Jonathan Kew
Andrew Osmond
Makoto Kato
Matt Woodrow
Jason Orendorff
Jonathan Kingston
Gurzau Raul
Valentin Gosu
nbeleuzu@mozilla.com
Nicholas Nethercote
Andreas Pehrson
Xidorn Quan
Tooru Fujisawa
Andreea Pavel
Dorel Luca
Noemi Erli
Jeff Walden
Margareta Eliza Balazs
Masayuki Nakano
Marco Bonardo
Jon Coppeard
Nathan Froyd
Ciure Andrei
Tom Ritter
Ryan Hunt