The new pref is "network.dns.resolver-thread-extra-idle-time-seconds"
The default is 60 seconds. This means that threads will stay idle for an extra 60 seconds, after which they are shutdown.
Setting the pref to 0 would preserve the behaviour before the threads were swiched to use nsThreadPool - meaning that they would be shutdown immediately after ThreadFunc completes.
Setting the pref to -1 would keep the threads alive forever.
MozReview-Commit-ID: CoUB5gan4MR
--HG--
extra : rebase_source : 7b444789eebaf43c939ce9d7153218c4cd594b65
Instead of creating and deleteing each thread, we use a nsThreadPool with a max of 8 resolver threads.
Whereas before each thread would run ThreadFunc exactly once then shut down, the threads may now remain active for a while. During this time we may post another task(runnable) to the thread.
MozReview-Commit-ID: FiE370ic1ah
--HG--
extra : rebase_source : 065bbf1f9867dfb38ac7b13816d4d06824d3a05d
This reduced the additional string duplication that we currently do every time
we add a preference observer.
It changes the string that we store in the observer objects to be absolute,
rather than relative to the branch, but keeps the semantics the same, by
resolving the full preference name in the places we were previously matching
by relative string.
This actually has the effect of simplifying a lot of code, since the absolute
preference name is usually what we want.
MozReview-Commit-ID: 10WjHb0tNGB
--HG--
extra : rebase_source : b3cb0ba103fc239e42459e77cd389db0b5ecde18
Most preference callbacks use literal strings for their domain filters, which
means that there's no need to make copies of them at all. Currently, however,
every preference observer node makes a separate heap-allocated copy of its
domain string.
This patch switches the domain string storage to nsCString instances, which
dramatically reduces the amount of unnecessary copies, at the expense of
making the callback nodes slightly larger.
MozReview-Commit-ID: 8NA3t2JS2UI
--HG--
extra : rebase_source : 628ad9af65cec16fb8be0c8dddc608b5ee5602e2
There seem race conditions that we do a paint process when we started observing
the refresh driver but the first tick hasn't happened yet.
MozReview-Commit-ID: KRP8WR644q1
These cause us to load Console.jsm and create a ConsoleAPI instance in every
content process, which is expensive both in terms of memory and startup
performance.
Checking the log level before we touch the console object is much cheaper,
in terms of both memory and performance.
MozReview-Commit-ID: 19f0ggAda2J
--HG--
extra : source : 440ee3fab72afc5d483a5bb2b0630f3c2ed3212f
extra : absorb_source : 35ba172bb0e9da002bf1b733463b61ed214cf225
These cause us to load Console.jsm and create a ConsoleAPI instance in every
content process, which is expensive both in terms of memory and startup
performance.
Checking the log level before we touch the console object is much cheaper,
in terms of both memory and performance.
MozReview-Commit-ID: 19f0ggAda2J
--HG--
extra : rebase_source : 38077a14122d201d11079330565d82f6f963b428
This call was added in bug 929362, but the key factor to fix the bug was just
setting a flag representing that the target frame doesn't allow the animation
running on the compositor and checking the flag in the function whether the
animation can be run on the compositor or not in later ticks. So the call
wasn't necessary in the first place.
The test case here fails without this fix. The test case actually doesn't
observe animation restyle count at all, so it might look a bit awkward in
file_restyles.html, if we add other test cases checking SchedulePaint calls
in future, we will move the tests in a different file.
(The reason there is no animation restyles in this case is that we properly
throttle the animation in this case.)
MozReview-Commit-ID: AyHciRJHM0s
--HG--
extra : rebase_source : f3963336ea9165b0a9c1a662bdac5c645b209219
Take AutoSaveLiveRegisters as an argument, and use that to ensure the registers were saved
--HG--
extra : rebase_source : bb54592bd009afc67aaa0ca9c705ab28f4a45d44
Automatic update from web-platform-testsClean up budget-api idl test (#11445)
Follow up for #9763 now that #10338 is resolved and we have #10381 too.
--
wpt-commits: 7b2cd8b78d938ea8879adc6419f2ea14b6af8bad
wpt-pr: 11445
Automatic update from web-platform-testsUpdate the IDL generated content headers to the content from reffy-reports (#11333)
--
wpt-commits: cdf41ff70d042eb78f461aeb44a5ad383964dbd3
wpt-pr: 11333
Automatic update from web-platform-tests[LayoutNG] Orthogonal flows need available inline size for min/max calculation.
Provide a suitable constraint space when calculating min/max inline
sizes for an orthogonal flow root. ComputeMinMaxSize() in NGBlockNode
typically ended up creating its zero-sized constraint space, which would
typically result in large block sizes (since there'd e.g. only be space
for one word per line).
Set percentage resolution size too, instead of leaving it at 0x0.
Percentages are often unresolvable (i.e. indefinite), in which case we
should of course refrain from resolving them, rather than resolving the
percentage against zero (which we used to do).
Add a DCHECK that we're always provided with a constraint space when
calculating min/max for orthogonal flows, as using the zero-size one
will not produce the correct result.
Bug: 848225
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_layout_tests_layout_ng
Change-Id: Ic0aac380b2b733d3a55b25396c89584e4468899d
Reviewed-on: https://chromium-review.googlesource.com/1090845
Commit-Queue: Morten Stenshorne <mstensho@chromium.org>
Reviewed-by: Aleks Totic <atotic@chromium.org>
Reviewed-by: Koji Ishii <kojii@chromium.org>
Reviewed-by: Christian Biesinger <cbiesinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#565446}
--
wpt-commits: ce22baff58c81ab98f3cbd2ac390e51e755fd9f9
wpt-pr: 11417
Ciure Andrei
Andreea Pavel
Andrea Marchesini
Kris Maglione
Jan-Erik Rediger
Valentin Gosu
Razvan Caliman
Daniel Stenberg
Emilio Cobos Álvarez
Dave Hunt
Hiroyuki Ikezoe
Nathan Froyd
Coroiu Cristina
Gabriel Luong
Matthew Gaudet
Dorel Luca
Drew Willcoxon
Arnaud Bienner
Kanika Saini
Paolo Amadini
Olli Pettay
moz-wptsync-bot
Luke Bjerring
Anne van Kesteren
Morten Stenshorne