39eb8d76e6b46d12e6353d0a336554f503e792df: Bug 1471025: Part 4 - Add a wrapper class that can access either static or dynamic prefs. r?njn draft
Kris Maglione <maglione.k@gmail.com> - Sun, 01 Jul 2018 23:23:48 -0700 - rev 814237
Push 115142 by maglione.k@gmail.com at Wed, 04 Jul 2018 20:49:19 +0000
Bug 1471025: Part 4 - Add a wrapper class that can access either static or dynamic prefs. r?njn The in-memory format of shared-memory preferences is significantly different from the format used by dynamic preferences, which means that we need different classes to access their properties. Virtual classes would be a potential solution to this problem, but I don't think the performance characteristics would be acceptable for preferences code. And since the wrapper classes used for static prefs are temporary, they would add the additional snag of figuring out how to keep a valid pointer alive. So, instead, this patch adds a wrapper class that can access eaither type of preference, based on known type flags in a Variant. It also moves some of the logic for deciding which preference value to return to the wrapper, so that it doesn't need to be duplicated for each representation. MozReview-Commit-ID: LameIIbYcD3
11c6ff7f39306f173fa07ed17f52af1a7d821326: Bug 1471025: Part 3c - Also pass the shared preference map handle to Android content processes. r?jld draft
Kris Maglione <maglione.k@gmail.com> - Mon, 02 Jul 2018 15:17:48 -0700 - rev 814236
Push 115142 by maglione.k@gmail.com at Wed, 04 Jul 2018 20:49:19 +0000
Bug 1471025: Part 3c - Also pass the shared preference map handle to Android content processes. r?jld MozReview-Commit-ID: CTjDzVC9gcD
58e6d5a2d7dbc383ec210caf37c0e43496c5159c: Bug 1471025: Part 3b - Refactor Android shared FD API to require fewer modifications per change. r?jld draft
Kris Maglione <maglione.k@gmail.com> - Mon, 02 Jul 2018 15:01:25 -0700 - rev 814235
Push 115142 by maglione.k@gmail.com at Wed, 04 Jul 2018 20:49:19 +0000
Bug 1471025: Part 3b - Refactor Android shared FD API to require fewer modifications per change. r?jld Adding or removing an FD from this API currently requires changes in about a half dozen places. Ignoring the Java side of things. This patch changes the API to pass a struct, rather than additional arguments for each FD, so that adding and removing FDs only requires changing one declaration, and the two call sites that add and comsume the FDs. MozReview-Commit-ID: CToSEVp1oqP
a491521e6f9843b4c5262f3d08561459c0ff0c2e: Bug 1471025: Part 3a - Pass shared preference map to (non-Android) content processes at startup. r?jld,njn draft
Kris Maglione <maglione.k@gmail.com> - Mon, 02 Jul 2018 15:40:38 -0700 - rev 814234
Push 115142 by maglione.k@gmail.com at Wed, 04 Jul 2018 20:49:19 +0000
Bug 1471025: Part 3a - Pass shared preference map to (non-Android) content processes at startup. r?jld,njn This adds an additional file descriptor to the set sent at content process startup, for the read-only preference map that we share between all content processes. This forms the base set of preferences. The other preferences FD contains changes that the content process will need to apply on top of the snapshot. MozReview-Commit-ID: 6hc0HIxFmHg
8dde48fbdbbdb1a87fdb7cccd0d39c46def2f758: Bug 1471025: Part 2 - Add a helper class creating and accessing shared preference map snapshots. r?njn,erahm draft
Kris Maglione <maglione.k@gmail.com> - Sun, 01 Jul 2018 18:28:31 -0700 - rev 814233
Push 115142 by maglione.k@gmail.com at Wed, 04 Jul 2018 20:49:19 +0000
Bug 1471025: Part 2 - Add a helper class creating and accessing shared preference map snapshots. r?njn,erahm This is based on the SharedStringMap that's currently used for shared memory string bundles. When the parent process is ready to launch its first content process, it creates a snapshot of the current state of the preference database, maps that as read-only, and shares it with each content process. Look-ups in the snapshotted map are done entirely using data in the shared memory region. It doesn't require any additional per-process state data. MozReview-Commit-ID: BdTUhak7dmS
236e7032a4586eb9e55ca0a4c9b4bd8bab1c8309: Bug 1471025: Part 1 - Store preference access counts in a separate hashtable. r?njn draft
Kris Maglione <maglione.k@gmail.com> - Mon, 02 Jul 2018 23:33:28 -0700 - rev 814232
Push 115142 by maglione.k@gmail.com at Wed, 04 Jul 2018 20:49:19 +0000
Bug 1471025: Part 1 - Store preference access counts in a separate hashtable. r?njn Once the majority of preferences are stored in a read-only shared map, it won't be possible to modify the access counts in their entries. Which means we need a separate map for the access counts. Fortunately, this code is only active in debug builds, so it shouldn't affect release users. And the net impact on memory usage of this patchset will still be decidedly downward. MozReview-Commit-ID: EuLXlMQJP1M
b8d27b6b40213e21ab36b387c4eff0af4591ee1d: [wip] JS pref getters. draft
Kris Maglione <maglione.k@gmail.com> - Sun, 01 Jul 2018 13:44:22 -0700 - rev 814231
Push 115142 by maglione.k@gmail.com at Wed, 04 Jul 2018 20:49:19 +0000
[wip] JS pref getters.
e2b5fe81a4c5c696425583a04395f2ae79aeaccc: Bug 1465505: Replace PRMJ_Now() by mozilla::TimeStamp r=jonco draft
Wander Lairson Costa <wcosta@mozilla.com> - Wed, 04 Jul 2018 16:55:11 -0300 - rev 814230
Push 115141 by bmo:wcosta@mozilla.com at Wed, 04 Jul 2018 19:55:38 +0000
Bug 1465505: Replace PRMJ_Now() by mozilla::TimeStamp r=jonco Notice as TimeStamp is not an integral type, it can't be wrapped by mozilla::Atomic. However, we wrap it in MainThreadData to assure it only is accessed from the main thread. Another issue is that TimeStamp class does allow some operations on a Null value, with assertions on debug builds. MozReview-Commit-ID: 9GPNDUooQmI
2a1704239e0fca8337b0d8d1c74ce79243e594bc: Bug 1442960 - Remove workaround for bug 1438504. r?bgrins draft
Dão Gottwald <dao@mozilla.com> - Wed, 04 Jul 2018 21:53:53 +0200 - rev 814229
Push 115140 by dgottwald@mozilla.com at Wed, 04 Jul 2018 19:54:29 +0000
Bug 1442960 - Remove workaround for bug 1438504. r?bgrins MozReview-Commit-ID: 9IdoPCF3LA5
f4121cc0b97ec8e361bec05a7e018a540005062e: Bug 1467824 - Raptor speedometer on google chrome on linux and windows7/10 (wip) draft
Rob Wood <rwood@mozilla.com> - Wed, 04 Jul 2018 14:21:04 -0400 - rev 814228
Push 115139 by rwood@mozilla.com at Wed, 04 Jul 2018 19:49:38 +0000
Bug 1467824 - Raptor speedometer on google chrome on linux and windows7/10 (wip) MozReview-Commit-ID: C0NU1QfJNWb
e7b99f8d656669688bbb3e5c460a13f077655ad5: Bug 1347204 - Implement the colors.ntp_background and colors.ntp_text properties. r=mconley, jaws draft
Tim Nguyen <ntim.bugs@gmail.com> - Thu, 12 Apr 2018 16:48:23 -0400 - rev 814227
Push 115138 by bmo:ntim.bugs@gmail.com at Wed, 04 Jul 2018 19:48:33 +0000
Bug 1347204 - Implement the colors.ntp_background and colors.ntp_text properties. r=mconley, jaws MozReview-Commit-ID: En8HajryiJS
8068cb14325a4fadfe20f00580a515ad0bcfc013: Bug 1347204 - Activity stream changes. r=andreio draft
Tim Nguyen <ntim.bugs@gmail.com> - Mon, 02 Jul 2018 13:49:44 +0100 - rev 814226
Push 115138 by bmo:ntim.bugs@gmail.com at Wed, 04 Jul 2018 19:48:33 +0000
Bug 1347204 - Activity stream changes. r=andreio MozReview-Commit-ID: JGVv1g6NYLU
f5e9c8844137b18c8a764c449eb01c8f3732b067: Bug 1471280 - Add new pref for how much longer resolver threads should remain idle draft
Valentin Gosu <valentin.gosu@gmail.com> - Wed, 04 Jul 2018 21:25:28 +0200 - rev 814225
Push 115137 by valentin.gosu@gmail.com at Wed, 04 Jul 2018 19:44:12 +0000
Bug 1471280 - Add new pref for how much longer resolver threads should remain idle 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
58e8c141cf41e2a7746612ae999c69af549bdeab: Bug 1471280 - Use nsThreadPool for DNS resolver threads draft
Valentin Gosu <valentin.gosu@gmail.com> - Wed, 04 Jul 2018 20:36:58 +0200 - rev 814224
Push 115137 by valentin.gosu@gmail.com at Wed, 04 Jul 2018 19:44:12 +0000
Bug 1471280 - Use nsThreadPool for DNS resolver threads 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
5b2fbbd4e2a9bde60063dcd180326a766159df09: Bug 1473379 - Change PaintedLayerData::mAssignedDisplayItems to a std::vector. r?mattwoodrow draft
Jamie Nicol <jnicol@mozilla.com> - Tue, 03 Jul 2018 22:39:04 -0400 - rev 814223
Push 115136 by bmo:jnicol@mozilla.com at Wed, 04 Jul 2018 19:37:09 +0000
Bug 1473379 - Change PaintedLayerData::mAssignedDisplayItems to a std::vector. r?mattwoodrow This allows us to call emplace_back, saving us a move. MozReview-Commit-ID: 4wRiAxl7LSN
f9eb887dc90f88c88f2a6a93aed019af12d62d60: Bug 1471280 - Add new pref for how much longer resolver threads should remain idle draft
Valentin Gosu <valentin.gosu@gmail.com> - Wed, 04 Jul 2018 21:25:28 +0200 - rev 814222
Push 115135 by valentin.gosu@gmail.com at Wed, 04 Jul 2018 19:34:39 +0000
Bug 1471280 - Add new pref for how much longer resolver threads should remain idle 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
ddb833437b3217b9a1b36393686d429a62b747c0: Bug 1471280 - Use nsThreadPool for DNS resolver threads draft
Valentin Gosu <valentin.gosu@gmail.com> - Wed, 04 Jul 2018 20:36:58 +0200 - rev 814221
Push 115135 by valentin.gosu@gmail.com at Wed, 04 Jul 2018 19:34:39 +0000
Bug 1471280 - Use nsThreadPool for DNS resolver threads 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
1102f5fd4b584ab0a1f11c215cf1f3d678a41732: Bug 1472788 - Use smart pointers in nsHostResolver::Create draft
Valentin Gosu <valentin.gosu@gmail.com> - Mon, 02 Jul 2018 21:19:01 +0200 - rev 814220
Push 115135 by valentin.gosu@gmail.com at Wed, 04 Jul 2018 19:34:39 +0000
Bug 1472788 - Use smart pointers in nsHostResolver::Create Differential Revision: https://phabricator.services.mozilla.com/D1916 MozReview-Commit-ID: 6YlnZss2TpP
782474c5b46feb1d9a11cba8017cf82e944ad2de: Bug 1467824 - Raptor speedometer on google chrome on linux64 draft
Rob Wood <rwood@mozilla.com> - Wed, 04 Jul 2018 14:21:04 -0400 - rev 814219
Push 115134 by rwood@mozilla.com at Wed, 04 Jul 2018 19:33:14 +0000
Bug 1467824 - Raptor speedometer on google chrome on linux64 MozReview-Commit-ID: 7aIhfIs2WCj
18cfcf4a10f35487d0ff9c946eb03ebca5880e1b: raptor - try installing chrome via ar draft
Rob Wood <rwood@mozilla.com> - Wed, 04 Jul 2018 14:05:14 -0400 - rev 814218
Push 115134 by rwood@mozilla.com at Wed, 04 Jul 2018 19:33:14 +0000
raptor - try installing chrome via ar MozReview-Commit-ID: 4jMlstSgsYo
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 tip