4b21b0a87ce34817928d1d0d539e9b6678e90b44: Bug 1351963 (part 7) - Factor out repeated thread-finding code. r=jseward.
Nicholas Nethercote <nnethercote@mozilla.com> - Fri, 24 Mar 2017 09:24:45 +1100 - rev 351038
Push 88785 by nnethercote@mozilla.com at Tue, 04 Apr 2017 05:28:52 +0000
Bug 1351963 (part 7) - Factor out repeated thread-finding code. r=jseward. The patch also adds a MOZ_RELEASE_ASSERT in profiler_unregister_thread() for the case where the ThreadInfo isn't found, which is informative.
72eac9880a00321b51bffa4c8c3f3ece491c3b2a: Bug 1351963 (part 6) - Remove ThreadInfo from TickSample. r=jseward.
Nicholas Nethercote <nnethercote@mozilla.com> - Fri, 31 Mar 2017 10:49:36 +1100 - rev 351037
Push 88785 by nnethercote@mozilla.com at Tue, 04 Apr 2017 05:28:52 +0000
Bug 1351963 (part 6) - Remove ThreadInfo from TickSample. r=jseward. This avoids the need for the fake ThreadInfo in profiler_get_backtrace(). It requires adding a few extra fields to TickSample.
281d225824a321f2f5a3cb94839146d22b5079e9: Bug 1351963 (part 5) - Improve TickSample. r=jseward.
Nicholas Nethercote <nnethercote@mozilla.com> - Fri, 31 Mar 2017 10:35:54 +1100 - rev 351036
Push 88785 by nnethercote@mozilla.com at Tue, 04 Apr 2017 05:28:52 +0000
Bug 1351963 (part 5) - Improve TickSample. r=jseward. This patch does the following. - Splits TickSample's constructor in two, one for the periodic sample case, and one for the synchronous sample case, and initializes more stuff in them. (The two constructors aren't that different right now, but they will become more different when I remove TickSample::mThreadInfo.) - Makes all the constructor-filled fields in TickSample |const|. - Reorders the fields so that the constructor-filled ones are before the ones that get filled in later. - Omits mContext on Mac via conditional compilation, to make the omission clearer.
bed8d9d6d6895cf35e4eaf9c12f3339a3a254025: Bug 1351963 (part 4) - Make the LastSample argument to addTagThreadId optional. r=jseward.
Nicholas Nethercote <nnethercote@mozilla.com> - Fri, 31 Mar 2017 10:13:13 +1100 - rev 351035
Push 88785 by nnethercote@mozilla.com at Tue, 04 Apr 2017 05:28:52 +0000
Bug 1351963 (part 4) - Make the LastSample argument to addTagThreadId optional. r=jseward. LastSample only makes sense for periodic samples, which are written to the global ProfileBuffer. It doesn't make sense for synchronous samples which are written to their own unshared buffer. At the moment it doesn't hurt to use them in this nonsensical way, but the ThreadInfo profiler_get_backtrace() will be removed soon, and we won't even have a LastSample to use nonsensically. So this patch makes the LastSample argument to addTagThreadId() optional. Which means we have to pass in a ThreadId, so there's no longer much point duplicating the ThreadId in LastSample, so the patch removes that field too. This avoids the possibility of the duplicate ThreadId failing to match, which is nice.
e4f4a089dc2dd14fb408e37a25d9f341bc4b56a6: Bug 1352074. Remove high precision timer mode from refresh driver because it is not needed with vsync based refresh drivers. r=mchang
Timothy Nikkel <tnikkel@gmail.com> - Tue, 04 Apr 2017 00:14:28 -0500 - rev 351034
Push 88784 by tnikkel@gmail.com at Tue, 04 Apr 2017 05:14:39 +0000
Bug 1352074. Remove high precision timer mode from refresh driver because it is not needed with vsync based refresh drivers. r=mchang Bug 731974 added this code to get more accurate timer callbacks back when the refresh driver was based on timers. It shouldn't be needed anymore now that the refresh driver is based on vsync.
5cc766c0864e83d4caaf4eb712d466a5c2d38809: Bug 1349699 - Assert that the Chromium channel is closed when MessageLoop is destroyed (r=dvander)
Bill McCloskey <billm@mozilla.com> - Mon, 20 Mar 2017 15:29:05 -0700 - rev 351033
Push 88783 by wmccloskey@mozilla.com at Tue, 04 Apr 2017 04:55:17 +0000
Bug 1349699 - Assert that the Chromium channel is closed when MessageLoop is destroyed (r=dvander) MozReview-Commit-ID: I7HyjVanlxJ
13f1d3918fe5a9363479c48fe0d6620aa2d77fe0: Bug 1349699 - Assert when destroying a MessageLoop that a live MessageChannel is attached to (r=dvander)
Bill McCloskey <billm@mozilla.com> - Mon, 20 Mar 2017 14:15:44 -0700 - rev 351032
Push 88783 by wmccloskey@mozilla.com at Tue, 04 Apr 2017 04:55:17 +0000
Bug 1349699 - Assert when destroying a MessageLoop that a live MessageChannel is attached to (r=dvander) MozReview-Commit-ID: GGr5UqJl3ui
a842ddcd299bd32a4a13f55f23b37de648a7cd13: Backed out 3 changesets (bug 1349699) for Android mozilla::ipc::MessageChannel::WillDestroyCurrentMessageLoop crashes
Phil Ringnalda <philringnalda@gmail.com> - Mon, 03 Apr 2017 21:07:49 -0700 - rev 351031
Push 88782 by philringnalda@gmail.com at Tue, 04 Apr 2017 04:07:58 +0000
Backed out 3 changesets (bug 1349699) for Android mozilla::ipc::MessageChannel::WillDestroyCurrentMessageLoop crashes Backed out changeset 8a50c2d76afc (bug 1349699) Backed out changeset 3b9eadd61e26 (bug 1349699) Backed out changeset 16e000b3fe0c (bug 1349699)
74eb0b08e42bd5c0ddd9f1b140cb98880f5377e8: Bug 1353187 - Guard access to the frame property table with a frame state bit. r=dholbert
L. David Baron <dbaron@dbaron.org> - Mon, 03 Apr 2017 20:43:31 -0700 - rev 351030
Push 88781 by dbaron@mozilla.com at Tue, 04 Apr 2017 03:46:19 +0000
Bug 1353187 - Guard access to the frame property table with a frame state bit. r=dholbert This protects all accesses to the frame property table with a bit stored on the frame. This means we avoid hashtable operations when asking about frame properties on frames that have no properties. The changes to RestyleManager, and the new HasSkippingBitCheck API, are needed because RestyleManager depended on being able to ask for properties on a deleted frame (knowing that the property in question could not have been set on any new frames since the deleted frame was destroyed), in order to use the destruction of the properties that happens at frame destruction as a mechanism for learning that the frame was destroyed. The changes there preserve the use of that mechanism, although it becomes a bit uglier. The ugliness is well-deserved. MozReview-Commit-ID: BScmDUlWq65
a86c4218ca5f2c1f5da6a0d0f415eef4f55331b6: Bug 1353187 - Give frame properties the const-ness semantics of member variables. r=dholbert
L. David Baron <dbaron@dbaron.org> - Mon, 03 Apr 2017 20:43:30 -0700 - rev 351029
Push 88781 by dbaron@mozilla.com at Tue, 04 Apr 2017 03:46:19 +0000
Bug 1353187 - Give frame properties the const-ness semantics of member variables. r=dholbert This makes it so that, given a |const nsIFrame*|, a caller can retrieve properties but not set or remove them, but with an |nsIFrame*| all operations are allowed. I believe this is sensible since properties act as extended member variables for things that are needed rarely, and these are the const-ness semantics of member variables. This also avoids the need for const_cast<nsIFrame*> to cast away const in the following patch, which guards property access with a frame state bit. MozReview-Commit-ID: IJ9JnGzdH51
dfdb5742823ae4ad1c54aa4aa293347336ed6c7f: Bug 1352889 - Ensure that PLDHashTable's second hash doesn't have padding with 0 bits for tables with capacity larger than 2^16. r=njn
L. David Baron <dbaron@dbaron.org> - Mon, 03 Apr 2017 20:43:30 -0700 - rev 351028
Push 88781 by dbaron@mozilla.com at Tue, 04 Apr 2017 03:46:19 +0000
Bug 1352889 - Ensure that PLDHashTable's second hash doesn't have padding with 0 bits for tables with capacity larger than 2^16. r=njn PLDHashTable takes the result of the hash function and multiplies it by kGoldenRatio to ensure that it has a good distribution of bits across the 32-bit hash value, and then zeroes out the low bit so that it can be used for the collision flag. This result is called hash0. From hash0 it computes two different numbers used to find entries in the table storage: hash1 is used to find an initial position in the table to begin searching for an entry; hash2 is then used to repeatedly offset that position (mod the size of the table) to build a chain of positions to search. In a table with capacity 2^c entries, hash1 is simply the upper c bits of hash0. This patch does not change this. Prior to this patch, hash2 was the c bits below hash1, padded at the low end with zeroes when c > 16. (Note that bug 927705, changeset 1a02bec165e16f370cace3da21bb2b377a0a7242, increased the maximum capacity from 2^23 to 2^26 since 2^23 was sometimes insufficient!) This manner of computing hash2 is problematic because it increases the risk of long chains for very large tables, since there is less variation in the hash2 result due to the zero padding. So this patch changes the hash2 computation by using the low bits of hash0 instead of shifting it around, thus avoiding 0 bits in parts of the hash2 value that are significant. Note that this changes what hash2 is in all cases except when the table capacity is exactly 2^16, so it does change our hashing characteristics. For tables with capacity less than 2^16, it should be using a different second hash, but with the same amount of random-ish data. For tables with capacity greater than 2^16, it should be using more random-ish data. MozReview-Commit-ID: JvnxAMBY711
8f8e8cd713ad1d08e756c329b45004fa9cea1946: Bug 1352888 - Don't set the collision flag when adding to PLDHashTable if we've already found the entry we're going to add. r=njn
L. David Baron <dbaron@dbaron.org> - Mon, 03 Apr 2017 20:43:29 -0700 - rev 351027
Push 88781 by dbaron@mozilla.com at Tue, 04 Apr 2017 03:46:19 +0000
Bug 1352888 - Don't set the collision flag when adding to PLDHashTable if we've already found the entry we're going to add. r=njn PLDHashTable's entry store has two types of unoccupied entries: free entries and removed entries. The search of a chain of entries (determined by the hash value) in the entry store to search for an entry can stop at free entries, but it continues across removed entries, because removed entries are entries that may have been skipped over when we were adding the value we're searching for to the hash, but have since been removed. For live entries, we also maintain this distinction by using one bit of storage for a collision flag, which notes that if the hashtable entry is removed, its place in the entry store must become a removed entry rather than a free entry. When we add a new entry to the table, Add's semantics require that we return an existing entry if there is one, and only create a new entry if no existing entry exists. (Bug 1352198 suggests the possibility of a faster alternative Add API where the caller guarantees that the key is not already in the hashtable.) When we search for the existing entry, we must thus continue the search across removed entries, even though we record the first removed entry found to return if the search for an existing entry fails. The existing code adds the collision flag through the entire table search during an Add. This patch changes that behavior so that we only add the collision flag prior to finding the first removed entry. Adding it after we find the first removed entry is unnecessary, since we are not making that entry part of a path to a new entry. If it is part of a path to an existing entry, it will already have the collision flag set. This patch effectively puts an if (!firstRemoved) around the else branch of the if (MOZ_UNLIKELY(EntryIsRemoved(entry))), and then refactors that condition outwards since it is now around the contents of both the if and else branches. MozReview-Commit-ID: CsXnMYttHVy
a52e75fdda073ca38e2a88b91ad7070c4138d702: Bug 1277709 - Make threadsafe reference counting use the minimum memory sychronization needed. r=froydnj
L. David Baron <dbaron@dbaron.org> - Mon, 03 Apr 2017 20:43:29 -0700 - rev 351026
Push 88781 by dbaron@mozilla.com at Tue, 04 Apr 2017 03:46:19 +0000
Bug 1277709 - Make threadsafe reference counting use the minimum memory sychronization needed. r=froydnj This uses std::atomic rather than mozilla::Atomic since mozilla::Atomic does not support using different memory synchronization for different atomic operations on the same variable. The added comments could use careful review since, while they reflect my understanding of the issue, I don't consider myself an expert on the topic. MozReview-Commit-ID: 7xByCXt17Dr
8a50c2d76afcdfa17697812b57de60304125903b: Bug 1349699 - Fix ASAN builds
Bill McCloskey <billm@mozilla.com> - Mon, 03 Apr 2017 20:08:02 -0700 - rev 351025
Push 88780 by wmccloskey@mozilla.com at Tue, 04 Apr 2017 03:08:08 +0000
Bug 1349699 - Fix ASAN builds MozReview-Commit-ID: 9tsL7nzjbpS
3b9eadd61e260fd307b7fcacc683e9536f70e62e: Bug 1349699 - Assert that the Chromium channel is closed when MessageLoop is destroyed (r=dvander)
Bill McCloskey <billm@mozilla.com> - Mon, 20 Mar 2017 15:29:05 -0700 - rev 351024
Push 88779 by wmccloskey@mozilla.com at Tue, 04 Apr 2017 02:41:23 +0000
Bug 1349699 - Assert that the Chromium channel is closed when MessageLoop is destroyed (r=dvander) MozReview-Commit-ID: I7HyjVanlxJ
16e000b3fe0c1a13e5c336e3cef1e082f2905dc0: Bug 1349699 - Assert when destroying a MessageLoop that a live MessageChannel is attached to (r=dvander)
Bill McCloskey <billm@mozilla.com> - Mon, 20 Mar 2017 14:15:44 -0700 - rev 351023
Push 88779 by wmccloskey@mozilla.com at Tue, 04 Apr 2017 02:41:23 +0000
Bug 1349699 - Assert when destroying a MessageLoop that a live MessageChannel is attached to (r=dvander) MozReview-Commit-ID: GGr5UqJl3ui
5fe4faa141d48eed2a6c43dde8b08fb2d7f00cec: Bug 1350724 - Remove telemetry for tab cache position (r=mconley)
Bill McCloskey <billm@mozilla.com> - Mon, 03 Apr 2017 14:12:39 -0700 - rev 351022
Push 88779 by wmccloskey@mozilla.com at Tue, 04 Apr 2017 02:41:23 +0000
Bug 1350724 - Remove telemetry for tab cache position (r=mconley) MozReview-Commit-ID: 5yJUeC2HxPs
d411840d6206cb515a20bcb60b5d4f8eb0f1335b: Bug 1352929 - Update libcubeb to 04826edb. r=padenot
Matthew Gregan <kinetik@flim.org> - Mon, 03 Apr 2017 15:22:46 +1200 - rev 351021
Push 88778 by mgregan@mozilla.com at Tue, 04 Apr 2017 02:02:34 +0000
Bug 1352929 - Update libcubeb to 04826edb. r=padenot
b3b4cf61e1479b86f448c3790883956b9a06740b: Bug 1244091 - Switch nsUpdateDriver to LazyLogModule. r=froydnj
Eric Rahm <erahm@mozilla.com> - Mon, 03 Apr 2017 18:36:18 -0700 - rev 351020
Push 88777 by erahm@mozilla.com at Tue, 04 Apr 2017 01:36:29 +0000
Bug 1244091 - Switch nsUpdateDriver to LazyLogModule. r=froydnj
6d446e9be0749c744f80370d63287e6316d15766: Bug 1351963 (part 3, attempt 2) - Remove ThreadInfo from ProfilerBacktrace. r=mstange.
Nicholas Nethercote <nnethercote@mozilla.com> - Tue, 04 Apr 2017 09:41:53 +1000 - rev 351019
Push 88776 by nnethercote@mozilla.com at Mon, 03 Apr 2017 23:51:51 +0000
Bug 1351963 (part 3, attempt 2) - Remove ThreadInfo from ProfilerBacktrace. r=mstange.
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 +100000 tip