6c84c452a23d74285685bab25f501aac12cd62a8: Bug 1202497 - part 7 - make nsEventQueue use external locking; r=gerald
Nathan Froyd <froydnj@mozilla.com> - Sun, 20 Sep 2015 05:13:09 -0400 - rev 297180
Push 5392 by raliiev@mozilla.com at Mon, 14 Dec 2015 20:08:23 +0000
Bug 1202497 - part 7 - make nsEventQueue use external locking; r=gerald We want to ensure that nsThread's use of nsEventQueue uses locking done in nsThread instead of nsEventQueue, for efficiency's sake: we only need to lock once in nsThread, rather than the current situation of locking in nsThread and additionally in nsEventQueue. With the current structure of nsEventQueue, that would mean that nsThread should be using a Monitor internally, rather than a Mutex. Which would be well and good, except that DOM workers use nsThread's mutex to protect their own, internal CondVar. Switching nsThread to use a Monitor would mean that either: - DOM workers drop their internal CondVar in favor of nsThread's Monitor-owned CondVar. This change seems unlikely to work out well, because now the Monitor-owned CondVar is performing double duty: tracking availability of events in nsThread's event queue and additionally whatever DOM workers were using a CondVar for. Having a single CondVar track two things in such a fashion is for Experts Only. - DOM workers grow their own Mutex to protect their own CondVar. Adding a mutex like this would change locking in subtle ways and seems unlikely to lead to success. Using a Monitor in nsThread is therefore untenable, and we would like to retain the current Mutex that lives in nsThread. Therefore, we need to have nsEventQueue manage its own condition variable and push the required (Mutex) locking to the client of nsEventQueue. This scheme also seems more fitting: external clients merely need synchronized access to the event queue; the details of managing notifications about events in the event queue should be left up to the event queue itself. Doing so also forces us to merge nsEventQueueBase and nsEventQueue: there's no way to have nsEventQueueBase require an externally-defined Mutex and then have nsEventQueue subclass nsEventQueueBase and provide its own Mutex to the superclass. C++ initialization rules (and the way things like CondVar are constructed) simply forbid it. But that's OK, because we want a world where nsEventQueue is externally locked anyway, so there's no reason to have separate classes here. One casualty of this work is removing ChaosMode support from nsEventQueue. nsEventQueue had support to delay placing events into the queue, theoretically giving other threads the chance to put events there first. Unfortunately, since the thread would have been holding a lock (as is evident from the MutexAutoLock& parameter required), sleeping in PutEvent accomplishes nothing but delaying the thread from getting useful work done. We should support this, but it's complicated to figure out how to reasonably support this right now. A wrinkle in this overall pleasant refactoring is that nsThreadPool's threads wait for limited amounts of time for new events to be placed in the event queue, so that they can shut themselves down if no new events are appearing. Setting limits on the number of threads also needs to be able to wake up all threads, so threads can shut themselves down if necessary. Unfortunately, with the transition to nsEventQueue managing its own condition variable, there's no way for nsThreadPool to perform these functions, since there's no Monitor to wait on. Therefore, we add a private API for accessing the condition variable and performing the tasks nsThreadPool needs. Prior to all the previous patches, placing items in an nsThread's event queue required three lock/unlock pairs: one for nsThread's Mutex, one to enter nsEventQueue's ReentrantMonitor, and one to exit nsEventQueue's ReentrantMonitor. The upshot of all this work is that we now only require one lock/unlock pair in nsThread itself, as things should be.
724c37f692544fd9e828c4a4bfecc99b30ec4439: Bug 1202497 - part 6 - make the locking requirements of nsEventQueue explicit; r=gerald
Nathan Froyd <froydnj@mozilla.com> - Mon, 21 Sep 2015 04:34:51 -0400 - rev 297179
Push 5392 by raliiev@mozilla.com at Mon, 14 Dec 2015 20:08:23 +0000
Bug 1202497 - part 6 - make the locking requirements of nsEventQueue explicit; r=gerald Like the previous patch, this patch is a no-op change in terms of functionality. It does, however, pave part of the way for forcing clients of nsEventQueue to provide their own locking.
4b7e7220cfa36ac8ed3d9dfd3449584bf3c16266: Bug 1202497 - part 5 - make the locking requirements of nsChainedEventQueue explicit; r=gerald
Nathan Froyd <froydnj@mozilla.com> - Sun, 20 Sep 2015 04:59:56 -0400 - rev 297178
Push 5392 by raliiev@mozilla.com at Mon, 14 Dec 2015 20:08:23 +0000
Bug 1202497 - part 5 - make the locking requirements of nsChainedEventQueue explicit; r=gerald This patch is a no-op in terms of functionality. It ensures that we're always holding nsThread's mutex when we touch mEvents, as dictated by the comments. Putting this addition into its own patch will help make the change to having nsEventQueue by guarded by a Mutex, rather than a Monitor, somewhat clearer.
01738e908455080ed7106fe9cd74218c683271d3: Bug 1202497 - part 4 - lock around call to nsChainedEventQueue::HasPendingEvent; r=gerald
Nathan Froyd <froydnj@mozilla.com> - Sun, 20 Sep 2015 04:47:10 -0400 - rev 297177
Push 5392 by raliiev@mozilla.com at Mon, 14 Dec 2015 20:08:23 +0000
Bug 1202497 - part 4 - lock around call to nsChainedEventQueue::HasPendingEvent; r=gerald This is another case of an access to mEvents not being protected by mLock. Future patches will make this locking requirement explicit in nsChainedEventQueue, so we won't have problems like this. (Since nsEventQueue has its own locking at this point, this omission didn't matter much, but the omission will most certainly matter later.)
9a7d7cf319865cd65ad8875abc147720a827332a: Bug 1202497 - part 3 - remove nsThread::GetEvent; r=gerald
Nathan Froyd <froydnj@mozilla.com> - Sun, 20 Sep 2015 04:44:51 -0400 - rev 297176
Push 5392 by raliiev@mozilla.com at Mon, 14 Dec 2015 20:08:23 +0000
Bug 1202497 - part 3 - remove nsThread::GetEvent; r=gerald GetEvent was only called from one place, so it wasn't terribly useful as an abstraction. It also broke the invariant that we protect accesses to mEvents with mLock, as documented in nsThread.h. While upcoming patches could have just updated GetEvent to do the necessary locking on its own, it seemed just as easy to make the locking requirements at the callsite, as will be done for other accesses to mEvents.
57e22eab392bd97ebb7fdbe69774269bf6779e66: Bug 1202497 - part 2 - remove ReentrantMonitor specializations for nsEventQueueBase; r=gerald
Nathan Froyd <froydnj@mozilla.com> - Sun, 20 Sep 2015 04:17:05 -0400 - rev 297175
Push 5392 by raliiev@mozilla.com at Mon, 14 Dec 2015 20:08:23 +0000
Bug 1202497 - part 2 - remove ReentrantMonitor specializations for nsEventQueueBase; r=gerald Now that nsEventQueue no longer depends on ReentrantMonitors, we can get rid of these unused specializations.
ec99404c8d3d18a68114987356bf0cd640dd963c: Bug 1202497 - part 1 - switch nsEventQueue to use a non-reentrant Monitor; r=gerald
Nathan Froyd <froydnj@mozilla.com> - Mon, 14 Sep 2015 21:52:08 -0400 - rev 297174
Push 5392 by raliiev@mozilla.com at Mon, 14 Dec 2015 20:08:23 +0000
Bug 1202497 - part 1 - switch nsEventQueue to use a non-reentrant Monitor; r=gerald nsEventQueue's monitor does not require re-entrancy now that the monitor is not externally visible. Since ReentrantMonitors require two separate mutex lock/unlock pairs (one on entry, and one on exit), this cuts the amount of locking nsEventQueue's methods do by half.
a4c070c0fac0c70b4b4d9257ac45417e22637f76: Bug 1206900: Add telemetry for device types captured with getUserMedia() r=jib,smaug
Randell Jesup <rjesup@jesup.org> - Mon, 21 Sep 2015 22:20:45 -0400 - rev 297173
Push 5392 by raliiev@mozilla.com at Mon, 14 Dec 2015 20:08:23 +0000
Bug 1206900: Add telemetry for device types captured with getUserMedia() r=jib,smaug
30d5d66ab33c33412f799e517fb98e0ef32bef01: Bug 1204857 - Report an error if there's trailing garbage after parsing a module r=efaust
Jon Coppeard <jcoppeard@mozilla.com> - Tue, 22 Sep 2015 14:03:20 +0100 - rev 297172
Push 5392 by raliiev@mozilla.com at Mon, 14 Dec 2015 20:08:23 +0000
Bug 1204857 - Report an error if there's trailing garbage after parsing a module r=efaust
1eb3ef642abaa4773fca10b763ddb13795d9bcdf: Bug 1191576 - Fix JIT invalidation spew to work when called while compacting r=terrence
Jon Coppeard <jcoppeard@mozilla.com> - Tue, 22 Sep 2015 14:03:19 +0100 - rev 297171
Push 5392 by raliiev@mozilla.com at Mon, 14 Dec 2015 20:08:23 +0000
Bug 1191576 - Fix JIT invalidation spew to work when called while compacting r=terrence
8a5ba14e09882ff6fb28a9a70f485ee039f23341: Bug 1206677 - Fix the NoGC version of NewStringCopyNDontDeflate() to not report error on failure r=jandem
Jon Coppeard <jcoppeard@mozilla.com> - Tue, 22 Sep 2015 14:03:19 +0100 - rev 297170
Push 5392 by raliiev@mozilla.com at Mon, 14 Dec 2015 20:08:23 +0000
Bug 1206677 - Fix the NoGC version of NewStringCopyNDontDeflate() to not report error on failure r=jandem
407ee28650b329870f4f18efea91f3a61957d81b: Bug 1206858 - Ensure that multiple concurrent calls to waitForAllPaints are handled properly. r=mattwoodrow
Kartikaya Gupta <kgupta@mozilla.com> - Tue, 22 Sep 2015 09:01:08 -0400 - rev 297169
Push 5392 by raliiev@mozilla.com at Mon, 14 Dec 2015 20:08:23 +0000
Bug 1206858 - Ensure that multiple concurrent calls to waitForAllPaints are handled properly. r=mattwoodrow
b0d6d89941a0ea0dd46fc5f1df026b8b7b85672d: Bug 1203390 follow-up: Move the mozilla-central/job_flags.yml entires to base_jobs.yml
Ehsan Akhgari <ehsan@mozilla.com> - Tue, 22 Sep 2015 08:50:06 -0400 - rev 297168
Push 5392 by raliiev@mozilla.com at Mon, 14 Dec 2015 20:08:23 +0000
Bug 1203390 follow-up: Move the mozilla-central/job_flags.yml entires to base_jobs.yml
2667d4232203489477ad9aa8e2019454a9ade339: Bug 1203393 follow-up: Address one review comment
Ehsan Akhgari <ehsan@mozilla.com> - Tue, 22 Sep 2015 08:44:25 -0400 - rev 297167
Push 5392 by raliiev@mozilla.com at Mon, 14 Dec 2015 20:08:23 +0000
Bug 1203393 follow-up: Address one review comment DONTBUILD
2fa98a89a2ee850ac30564a7d1ee69f28d7378d8: Bug 1206456 - Stop forcing mozilla-central Linux64 opt static analysis builds to be clobber; r=dustin
Ehsan Akhgari <ehsan@mozilla.com> - Sat, 19 Sep 2015 22:02:07 -0400 - rev 297166
Push 5392 by raliiev@mozilla.com at Mon, 14 Dec 2015 20:08:23 +0000
Bug 1206456 - Stop forcing mozilla-central Linux64 opt static analysis builds to be clobber; r=dustin
0cf091991709f3dec251c0cd922d5c8eab9f4a93: Bug 1203397 - Show Linux64 static analysis builds as "S" in TreeHerder; r=dustin
Ehsan Akhgari <ehsan@mozilla.com> - Thu, 10 Sep 2015 21:38:02 -0400 - rev 297165
Push 5392 by raliiev@mozilla.com at Mon, 14 Dec 2015 20:08:23 +0000
Bug 1203397 - Show Linux64 static analysis builds as "S" in TreeHerder; r=dustin
fffacdefdd8d9fe813f3684de056d818e50a4265: Bug 1203390 - Add support for Linux64 Static Analysis opt builds using TaskCluster; r=dustin
Ehsan Akhgari <ehsan@mozilla.com> - Thu, 03 Sep 2015 21:46:29 -0400 - rev 297164
Push 5392 by raliiev@mozilla.com at Mon, 14 Dec 2015 20:08:23 +0000
Bug 1203390 - Add support for Linux64 Static Analysis opt builds using TaskCluster; r=dustin
0bbd5abafd45018a1879ed5868e9069b72d120e1: Bug 1206991 - Use mozconfig.cache in Linux static analysis builds; r=glandium
Ehsan Akhgari <ehsan@mozilla.com> - Mon, 21 Sep 2015 22:05:17 -0400 - rev 297163
Push 5392 by raliiev@mozilla.com at Mon, 14 Dec 2015 20:08:23 +0000
Bug 1206991 - Use mozconfig.cache in Linux static analysis builds; r=glandium
cdfbb524ec7df2cbbd8b8ed16dda14dce7345399: Bug 1203393 - Part 3: Add build configuration for Linux64 optimized Static Analysis builds; r=glandium
Ehsan Akhgari <ehsan@mozilla.com> - Thu, 10 Sep 2015 00:41:05 -0400 - rev 297162
Push 5392 by raliiev@mozilla.com at Mon, 14 Dec 2015 20:08:23 +0000
Bug 1203393 - Part 3: Add build configuration for Linux64 optimized Static Analysis builds; r=glandium Also update the compiler for Linux64 debug static analysis builds to match the one we use for optimized builds.
cf0e769b6e9fbfe7e9327b94d2702ce2847e82ff: Bug 1203393 - Part 2: Package clang as an xz archive; r=glandium
Ehsan Akhgari <ehsan@mozilla.com> - Wed, 16 Sep 2015 21:00:34 -0400 - rev 297161
Push 5392 by raliiev@mozilla.com at Mon, 14 Dec 2015 20:08:23 +0000
Bug 1203393 - Part 2: Package clang as an xz archive; r=glandium
(0) -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 +100000 tip