searching for reviewer(gregtatum)
eb147c90d7dbc7de17580f60cd6c1d5f3bbf0931: Bug 1578354 - Remove the obsolete condition so that JS frames are now properly filtered in in the call tree r=gregtatum a=lizzard
Julien Wajsberg <felash@gmail.com> - Thu, 05 Sep 2019 15:20:36 +0000 - rev 554903
Push 2165 by ffxbld-merge at Mon, 14 Oct 2019 16:30:58 +0000
Bug 1578354 - Remove the obsolete condition so that JS frames are now properly filtered in in the call tree r=gregtatum a=lizzard Bug 1557789 added categories to all JS frames, so as a result JS frames where all filtered out because of the condition removed in this patch. This condition is basically a premature optimization, removing it shouldn't bring any behavior difference. Differential Revision: https://phabricator.services.mozilla.com/D44803
243d7178baf8af12782eaeed566e00a086c852f7: Bug 1551313: Insert profiler markers when preferences are accessed. r=squib,gregtatum
Will Hawkins <whawkins@mozilla.com> - Fri, 23 Aug 2019 13:12:51 +0300 - rev 553324
Push 2165 by ffxbld-merge at Mon, 14 Oct 2019 16:30:58 +0000
Bug 1551313: Insert profiler markers when preferences are accessed. r=squib,gregtatum Reviewers: squib, mstange, gregtatum Reviewed By: squib, gregtatum Subscribers: julienw, Fallen, reviewbot, mixedpuppy, mstange Bug #: 1551313 Differential Revision: https://phabricator.services.mozilla.com/D39796
7fd9b797a83ea0e87994e0546b92b5c033385f7a: Bug 1551313: Insert profiler markers when preferences are accessed. r=squib,gregtatum
Will Hawkins <whawkins@mozilla.com> - Fri, 23 Aug 2019 00:21:53 +0000 - rev 553279
Push 2165 by ffxbld-merge at Mon, 14 Oct 2019 16:30:58 +0000
Bug 1551313: Insert profiler markers when preferences are accessed. r=squib,gregtatum Differential Revision: https://phabricator.services.mozilla.com/D39796
36da91720edeb7b1d1932fafbfc3f248efb239be: Bug 1575453 - Collect stats for sampling, and markers (add, collect, expire) - r=gregtatum
Gerald Squelart <gsquelart@mozilla.com> - Thu, 22 Aug 2019 01:01:25 +0000 - rev 553098
Push 2165 by ffxbld-merge at Mon, 14 Oct 2019 16:30:58 +0000
Bug 1575453 - Collect stats for sampling, and markers (add, collect, expire) - r=gregtatum Use AUTO_PROFILER_STATS in both profilers, in: - SamplerThread::Run() calling DoPeriodicSample() - racy_profiler_add_marker - ProfileBuffer::DeleteExpiredStoredMarkers() This should cover all areas affected by the upcoming changes to the ProfileBuffer storage, and how markers are stored. Differential Revision: https://phabricator.services.mozilla.com/D42826
e8848c8fdfdbd1e5ed9f9d8448b7e94a10ff9b9d: Bug 1575453 - AUTO_PROFILER_STATS (off by default) - r=gregtatum
Gerald Squelart <gsquelart@mozilla.com> - Thu, 22 Aug 2019 00:33:11 +0000 - rev 553097
Push 2165 by ffxbld-merge at Mon, 14 Oct 2019 16:30:58 +0000
Bug 1575453 - AUTO_PROFILER_STATS (off by default) - r=gregtatum AUTO_PROFILER_STATS(name) can be used to time a {block}. Statistics are gathered in a function-static variable, and printf'd when the program ends. Differential Revision: https://phabricator.services.mozilla.com/D42825
726df58871848b2e3e4585d44533cb360ce903e7: Bug 1575442 - BlocksRingBuffer::LockAndRun - r=gregtatum
Gerald Squelart <gsquelart@mozilla.com> - Thu, 22 Aug 2019 00:32:51 +0000 - rev 553096
Push 2165 by ffxbld-merge at Mon, 14 Oct 2019 16:30:58 +0000
Bug 1575442 - BlocksRingBuffer::LockAndRun - r=gregtatum Some users will want to lock the buffer but not do any specific operation with it. Differential Revision: https://phabricator.services.mozilla.com/D42824
f1ffc0607aa4e06cfb92ceb7a63c641f85c86908: Bug 1575158 - BlocksRingBufferGeckoExtensions.h - r=gregtatum
Gerald Squelart <gsquelart@mozilla.com> - Tue, 20 Aug 2019 22:52:34 +0000 - rev 552827
Push 2165 by ffxbld-merge at Mon, 14 Oct 2019 16:30:58 +0000
Bug 1575158 - BlocksRingBufferGeckoExtensions.h - r=gregtatum Some marker payloads rely on JS and XPCOM objects (e.g., nsCString), so we need to (de)serialize these. Differential Revision: https://phabricator.services.mozilla.com/D42635
c1009702108c15496485188db83d50c94bcfe29e: Bug 1575141 - BlocksRingBuffer::{S,Des}erializer<BlocksRingBuffer> - r=gregtatum
Gerald Squelart <gsquelart@mozilla.com> - Tue, 20 Aug 2019 21:33:52 +0000 - rev 552826
Push 2165 by ffxbld-merge at Mon, 14 Oct 2019 16:30:58 +0000
Bug 1575141 - BlocksRingBuffer::{S,Des}erializer<BlocksRingBuffer> - r=gregtatum Backtraces (that are kept in some marker payloads) are stored in a small ProfileBuffer, we will need to store that data, which will happen to be inside a BlockRingBuffer, so BlockRingBuffer needs to be able to (de)serialize itself! This is done by storing the contents in the active buffer range, and some extra data, to later reconstruct a BlocksRingBuffer that looks like the original. Depends on D42496 Differential Revision: https://phabricator.services.mozilla.com/D42634
fb4291c0a54bc2531c4a10066ba370126b26e2d4: Bug 1574896 - BlocksRingBuffer de/serialization methods and helpers - r=gregtatum
Gerald Squelart <gsquelart@mozilla.com> - Tue, 20 Aug 2019 22:39:12 +0000 - rev 552825
Push 2165 by ffxbld-merge at Mon, 14 Oct 2019 16:30:58 +0000
Bug 1574896 - BlocksRingBuffer de/serialization methods and helpers - r=gregtatum Markers and their payloads contain all kinds of objects that we'll need to serialize into a BlocksRingBuffer (new ProfileBuffer storage). This patch will add functions to: - Compute the size needed to store objects, - Write multiple objects into a BlockRingBuffer entry, - Read objects back from an entry. And it will provide a number of useful de/serialization helpers for: - Trivially-copyable objects, - Strings of different types, - Raw pointers (with some safety guards to avoid surprises), - Tuples (to store multiple sub-objects), - Spans, - Maybe (for optional objects), - Variant. This should be enough to store most kinds of data. Further specializations can&will be written as necessary for more complex or obscure types. Differential Revision: https://phabricator.services.mozilla.com/D42496
83a24536ae41fb4deb2659f800740f03c662118f: Bug 1574825 - Make ModuloBuffer::Iterator a proper random-access iterator - r=gregtatum
Gerald Squelart <gsquelart@mozilla.com> - Tue, 20 Aug 2019 12:51:31 +0000 - rev 552808
Push 2165 by ffxbld-merge at Mon, 14 Oct 2019 16:30:58 +0000
Bug 1574825 - Make ModuloBuffer::Iterator a proper random-access iterator - r=gregtatum This allows its use in std algorithms and types that require a real iterator (like `template <typename InputIt> std::string::string(InputIt, InputIt)`). Differential Revision: https://phabricator.services.mozilla.com/D42452
80ccb3da46c1d4334788a650b2af76c250fc78bd: Bug 1574824 - BlocksRingBuffer:SizeOf{Ex,In}cludingThis - r=gregtatum
Gerald Squelart <gsquelart@mozilla.com> - Tue, 20 Aug 2019 12:49:50 +0000 - rev 552807
Push 2165 by ffxbld-merge at Mon, 14 Oct 2019 16:30:58 +0000
Bug 1574824 - BlocksRingBuffer:SizeOf{Ex,In}cludingThis - r=gregtatum Differential Revision: https://phabricator.services.mozilla.com/D42451
c0fc68f4e71cd0b3ed164eb70587db2d7b8facf3: Bug 1574824 - ModuloBuffer:SizeOf{Ex,In}cludingThis - r=gregtatum
Gerald Squelart <gsquelart@mozilla.com> - Tue, 20 Aug 2019 12:49:32 +0000 - rev 552806
Push 2165 by ffxbld-merge at Mon, 14 Oct 2019 16:30:58 +0000
Bug 1574824 - ModuloBuffer:SizeOf{Ex,In}cludingThis - r=gregtatum Differential Revision: https://phabricator.services.mozilla.com/D42450
ec46cb015929f8b3692ea436aad737d53bf859eb: Bug 1574822 - BlocksRingBuffer::Reader::At() - r=gregtatum
Gerald Squelart <gsquelart@mozilla.com> - Tue, 20 Aug 2019 14:26:07 +0000 - rev 552805
Push 2165 by ffxbld-merge at Mon, 14 Oct 2019 16:30:58 +0000
Bug 1574822 - BlocksRingBuffer::Reader::At() - r=gregtatum `Reader::At()` can be used to get a `BlockIterator` at a given `BlockIndex`, clamped between `begin()` and `end()`. This will be useful when we want to iterate starting at a given index, e.g., when duplicating stacks. Differential Revision: https://phabricator.services.mozilla.com/D42449
28c9ee2e5e89bce1e916d06dddcd28f465e869c1: Bug 1574821 - TestBaseProfiler generates more labels and markers - r=gregtatum
Gerald Squelart <gsquelart@mozilla.com> - Tue, 20 Aug 2019 03:29:53 +0000 - rev 552627
Push 2165 by ffxbld-merge at Mon, 14 Oct 2019 16:30:58 +0000
Bug 1574821 - TestBaseProfiler generates more labels and markers - r=gregtatum The main goal of these bugs is to move markers to a new storage, so I'm adding lots of markers to TestBaseProfiler. Also adding labels, easier to read unsymbolicated profiles, and gives a bit more coverage too. And adding a separate "fibonacci canceller" thread, which is needed on some slower platforms (e.g., Linux 64 ASAN times out otherwise); as a bonus, this tests AUTO_BASE_PROFILER_REGISTER_THREAD. Differential Revision: https://phabricator.services.mozilla.com/D42448
e54b58ba5f3a177e8d3abbb5de1e10903a83910d: Bug 1574143 - Make BlocksRingBuffer::Reader RAII - r=gregtatum
Gerald Squelart <gsquelart@mozilla.com> - Fri, 16 Aug 2019 03:55:08 +0000 - rev 552185
Push 2165 by ffxbld-merge at Mon, 14 Oct 2019 16:30:58 +0000
Bug 1574143 - Make BlocksRingBuffer::Reader RAII - r=gregtatum In practice the Reader doesn't need to be copied/moved/reassign. BlocksRingBuffer::Read() can just instantiate one on the stack, and pass it by reference to callbacks. Differential Revision: https://phabricator.services.mozilla.com/D42118
2fd28586dfbe3ecc7a08a5dbec3cc39d2c838ee8: Bug 1574143 - Remove BlocksRingBuffer::EntryReserver - r=gregtatum
Gerald Squelart <gsquelart@mozilla.com> - Fri, 16 Aug 2019 03:54:49 +0000 - rev 552184
Push 2165 by ffxbld-merge at Mon, 14 Oct 2019 16:30:58 +0000
Bug 1574143 - Remove BlocksRingBuffer::EntryReserver - r=gregtatum The point of the EntryReserver was mainly to have an object that represented a writing lock on BlocksRingBuffer, so potentially perform multiple consecutive writes. After some experience implementing bug 1562604, there's actually no need for it. So instead of having `Put()` create an `EntryReserver`, we now have `ReserveAndPut()` that does the whole work in one function. Differential Revision: https://phabricator.services.mozilla.com/D42116
1050dca058c32f29609390345646ffde7e9f6114: Bug 1574143 - Make BlocksRingBuffer::EntryWriter RAII - r=gregtatum
Gerald Squelart <gsquelart@mozilla.com> - Fri, 16 Aug 2019 04:02:18 +0000 - rev 552183
Push 2165 by ffxbld-merge at Mon, 14 Oct 2019 16:30:58 +0000
Bug 1574143 - Make BlocksRingBuffer::EntryWriter RAII - r=gregtatum EntryWriter doesn't even need to be moveable, as BlocksRingBuffer can just create one on the stack, and pass it by reference to callbacks. This removes risks, and potential data copies. Differential Revision: https://phabricator.services.mozilla.com/D42115
1970740a923dfce6cb90064a98410672cd883894: Bug 1573111 - BlocksRingBuffer can switch underlying buffer - r=gregtatum
Gerald Squelart <gsquelart@mozilla.com> - Tue, 13 Aug 2019 12:06:40 +0000 - rev 551395
Push 2165 by ffxbld-merge at Mon, 14 Oct 2019 16:30:58 +0000
Bug 1573111 - BlocksRingBuffer can switch underlying buffer - r=gregtatum `BlocksRingBuffer` will be used both inside and outside `ProfileBuffer`: - Inside to serve as `ProfileBuffer`'s main storage for stack traces, - Outside to allow marker storage even when `ProfileBuffer` is locked during stack sampling. `ProfileBuffer` only exists while `ActivePS` is alive, but because of the potential outside accesses above (due to small races between ProfileBuffer shutdown, and thread-local IsBeingProfiled() flags), we cannot just do the same for BlocksRingBuffer, and it must remain alive to gracefully deny these accesses around the profiler startup and shutdown times. To accomplish this, `BlocksRingBuffer` may be in different states: - "In-session", we have a real buffer to write to and read from, - "Out-of-session", without buffer so reads&writes do nothing. This is implemented by enclosing the underlying `ModuloBuffer` and the entry deleter in a `Maybe`, which may be `Nothing` when the profiler is not running and the `ProfileBuffer`'s `BlocksRingBuffer` is out-of-session. Differential Revision: https://phabricator.services.mozilla.com/D41519
58dd47c5aa51acc3095c623148df986354dfbf72: Bug 1573111 - BlocksRingBuffer can switch underlying buffer - r=gregtatum
Gerald Squelart <gsquelart@mozilla.com> - Tue, 13 Aug 2019 03:11:53 +0000 - rev 551310
Push 2165 by ffxbld-merge at Mon, 14 Oct 2019 16:30:58 +0000
Bug 1573111 - BlocksRingBuffer can switch underlying buffer - r=gregtatum `BlocksRingBuffer` will be used both inside and outside `ProfileBuffer`: - Inside to serve as `ProfileBuffer`'s main storage for stack traces, - Outside to allow marker storage even when `ProfileBuffer` is locked during stack sampling. `ProfileBuffer` only exists while `ActivePS` is alive, but because of the potential outside accesses above (due to small races between ProfileBuffer shutdown, and thread-local IsBeingProfiled() flags), we cannot just do the same for BlocksRingBuffer, and it must remain alive to gracefully deny these accesses around the profiler startup and shutdown times. To accomplish this, `BlocksRingBuffer` may be in different states: - "In-session", we have a real buffer to write to and read from, - "Out-of-session", without buffer so reads&writes do nothing. This is implemented by enclosing the underlying `ModuloBuffer` and the entry deleter in a `Maybe`, which may be `Nothing` when the profiler is not running and the `ProfileBuffer`'s `BlocksRingBuffer` is out-of-session. Differential Revision: https://phabricator.services.mozilla.com/D41519
b7cecb1c435b78d0c8ae4228f9aca81cfda0d1c2: Bug 1572027 - Make BlocksRingBuffer::EntryReader move-only - r=gregtatum
Gerald Squelart <gsquelart@mozilla.com> - Wed, 07 Aug 2019 21:33:09 +0000 - rev 550592
Push 2165 by ffxbld-merge at Mon, 14 Oct 2019 16:30:58 +0000
Bug 1572027 - Make BlocksRingBuffer::EntryReader move-only - r=gregtatum After some bad experiences, I think EntryReader should be move-only: - It needs to be moveable so it can be created from a function, and move- constructed into a Maybe<> if needed. - It can be passed around as a reference. Previously, it could be passed by value, but it was too easy to create bugs, e.g.: A function delegates to a sub-function to read something at the beginning, then the first function wants to read more past that, but if the reader was passed by value the first function would not see past what the sub-function did read. As a bonus, `mRing` can now be a reference instead of a pointer, and other members can be const. Differential Revision: https://phabricator.services.mozilla.com/D40958
aa2bdd816d108a1450f8af489b4b0488e6b379c4: Bug 1571392 - Make BlocksRingBuffer::EntryWriter move-only - r=gregtatum
Gerald Squelart <gsquelart@mozilla.com> - Wed, 07 Aug 2019 01:54:45 +0000 - rev 550417
Push 2165 by ffxbld-merge at Mon, 14 Oct 2019 16:30:58 +0000
Bug 1571392 - Make BlocksRingBuffer::EntryWriter move-only - r=gregtatum It makes little sense to copy a writer (also an output iterator). We're keeping it move-constructible (so it can be passed around for construction purposes), but not move-assignable to help make more members `const`. Differential Revision: https://phabricator.services.mozilla.com/D40622
cdc5694c40a42a040882ab957316ed7df6d8e03f: Bug 1571390 - BlocksRingBuffer::GetState() takes a snapshot of the current state - r=gregtatum
Gerald Squelart <gsquelart@mozilla.com> - Wed, 07 Aug 2019 01:54:31 +0000 - rev 550416
Push 2165 by ffxbld-merge at Mon, 14 Oct 2019 16:30:58 +0000
Bug 1571390 - BlocksRingBuffer::GetState() takes a snapshot of the current state - r=gregtatum This makes it easier to grab all BlocksRingBuffer state variables: - Range start and end. - Number of pushed blocks/entries, number of cleared blocks/entries. The function is thread-safe, and the returned values are consistent with each other, but they may become stale straight after the function returns (and the lock is released). They are still valuable to statistics, and to know how far the range has at least reached (but may go further soon). Differential Revision: https://phabricator.services.mozilla.com/D40621
d15aca364d3d1a02054a962676e0d8270c1457b7: Bug 1571355 - Base Profiler mutex tweaks - r=gregtatum
Gerald Squelart <gsquelart@mozilla.com> - Wed, 07 Aug 2019 01:54:09 +0000 - rev 550415
Push 2165 by ffxbld-merge at Mon, 14 Oct 2019 16:30:58 +0000
Bug 1571355 - Base Profiler mutex tweaks - r=gregtatum Renamed `BPAutoLock` to `BaseProfilerAutoLock`. DEBUG-build `~BaseProfilerMutex()` checks that it is unlocked. Prevent `BaseProfilerMutex` and `BaseProfilerAutoLock` copies&moves. DEBUG-build check that `Lock()` sees `mOwningThreadId`==0 (because that is the initial value, and the value after a previous `Unlock()`). Don't preserve atomic `mOwningThreadId` in JS recording. Differential Revision: https://phabricator.services.mozilla.com/D40620
a1b7fe8bd39a7f721324250b8f3a9a61d6415049: Bug 1571348 - ProfilerMarkerPayload::Set...() can be replaced with constructor arguments - r=gregtatum
Gerald Squelart <gsquelart@mozilla.com> - Wed, 07 Aug 2019 01:53:55 +0000 - rev 550414
Push 2165 by ffxbld-merge at Mon, 14 Oct 2019 16:30:58 +0000
Bug 1571348 - ProfilerMarkerPayload::Set...() can be replaced with constructor arguments - r=gregtatum `ProfilerMarkerPayload::Set...()` functions are only used by derived classes in the same files, and these values could just be set during construction. Differential Revision: https://phabricator.services.mozilla.com/D40619
dee618137651ecd474c9747160f4debd758f4c98: Bug 1569458 - Use mMutex.AssertCurrentThreadOwns() in BlocksRingBuffer - r=gregtatum
Gerald Squelart <gsquelart@mozilla.com> - Tue, 30 Jul 2019 12:19:55 +0000 - rev 549181
Push 2165 by ffxbld-merge at Mon, 14 Oct 2019 16:30:58 +0000
Bug 1569458 - Use mMutex.AssertCurrentThreadOwns() in BlocksRingBuffer - r=gregtatum This of course checks that the mutex is locked as expected in non-public APIs. It also checks that user callbacks will not keep readers/writers longer than they should. Differential Revision: https://phabricator.services.mozilla.com/D39625
3357c0982cc2b6a26f15607588fb7e6983ae5afe: Bug 1569458 - Unify Base Profiler mutexes into one class - r=gregtatum
Gerald Squelart <gsquelart@mozilla.com> - Tue, 30 Jul 2019 12:19:54 +0000 - rev 549180
Push 2165 by ffxbld-merge at Mon, 14 Oct 2019 16:30:58 +0000
Bug 1569458 - Unify Base Profiler mutexes into one class - r=gregtatum `BaeProfilerMutex` is a concrete mutex based on MutexImpl, which was previously implemented twice in both platform.h and BlocksRingBuffer.h. This combined mutex has some DEBUG code (when MOZ_BASE_PROFILER is #defined) to catch recursive locking, and to assert that the mutex is held (for code that cannot easily use the "proof of lock" pattern; e.g., going through user-provided callbacks). This class needs to be public (because it is used in public headers), but is an implementation detail, so it is located in a new header "mozilla/BaseProfilerDetail.h" that will collect `mozilla::baseprofiler::detail` code that may be useful to a few files in Base Profiler. Differential Revision: https://phabricator.services.mozilla.com/D39624
f82460e974f96b52021eb4bb06121df138223e0f: Bug 1567861 - Fix BlocksRingBuffer::ClearBefore() with past-the-end BlockIndex - r=gregtatum
Gerald Squelart <gsquelart@mozilla.com> - Tue, 30 Jul 2019 07:24:20 +0000 - rev 549179
Push 2165 by ffxbld-merge at Mon, 14 Oct 2019 16:30:58 +0000
Bug 1567861 - Fix BlocksRingBuffer::ClearBefore() with past-the-end BlockIndex - r=gregtatum `ClearBefore()` with a past-the-end `BlockIndex` was calling `Clear()`, which tried to take the lock again! Also we didn't return after that. Fixed, and added corresponding test. Also: Removed ambiguous "delete" word, now using more precise "destroy" or "entry destructor". Differential Revision: https://phabricator.services.mozilla.com/D38846
d2ed1a96bb6a83db175668fd93aa25fb34094dad: Bug 1567465 - Default BlockIndex used as empty value index before any valid entry - r=gregtatum
Gerald Squelart <gsquelart@mozilla.com> - Fri, 19 Jul 2019 16:10:30 +0000 - rev 547362
Push 2165 by ffxbld-merge at Mon, 14 Oct 2019 16:30:58 +0000
Bug 1567465 - Default BlockIndex used as empty value index before any valid entry - r=gregtatum This is a similar concept as `nullptr` is to a pointer. `BlocksRingBuffer` now skips the first byte in the buffer, so that no entries start at 0 (the internal default `BlockIndex` value). All `BlocksRingBuffer` public APIs handle this default value, and do nothing and/or return Nothing (as if it pointed at an already-deleted entry). Added tests for this, and for all BlockIndex operations. Differential Revision: https://phabricator.services.mozilla.com/D38667
74908c04ec0ed6756ce2163e9392d18be0c8c3d2: Bug 1567461 - Ensure ModuloBuffer can be properly move-constructed - r=gregtatum
Gerald Squelart <gsquelart@mozilla.com> - Sat, 20 Jul 2019 00:13:59 +0000 - rev 547343
Push 2165 by ffxbld-merge at Mon, 14 Oct 2019 16:30:58 +0000
Bug 1567461 - Ensure ModuloBuffer can be properly move-constructed - r=gregtatum Without declaring them, ModuloBuffer had its copy&move constructor&assignments defaulted. This means it could have been copied, and then both objects would now own the same resource and attempt to free it on destruction! So now: - Copy construction&assignment are now explicitly disallowed. - Move assignment is disallowed, to keep some members `const`. - Move construction is allowed (so a function can return a ModuloBuffer), and ensures that the moved-from object won't free the resource anymore. Bonus: `mBuffer` is now `const`, to ensure that it cannot point at something else, but note the pointed-at bytes are *not* const. So ModuloBuffer is like an unchanging resource, but it allows to be moved-from as an xvalue that should not be used after the move. Differential Revision: https://phabricator.services.mozilla.com/D38665
0dac048b774a36f3116f25ae85b9ad8fa8c1f7c6: Bug 1566706 - ModuloBuffer and BlocksRingBuffer can be given a external underlying buffer - r=gregtatum
Gerald Squelart <gsquelart@mozilla.com> - Fri, 19 Jul 2019 00:56:18 +0000 - rev 547210
Push 2165 by ffxbld-merge at Mon, 14 Oct 2019 16:30:58 +0000
Bug 1566706 - ModuloBuffer and BlocksRingBuffer can be given a external underlying buffer - r=gregtatum By default `ModuloBuffer` allocates its own buffer on the heap. Now `ModuloBuffer` adds two alternatives: - Take ownership of a pre-allocated `UniquePtr<uint8_t>` buffer. - Work over an unowned `uint8_t*` array. The caller is responsible for ownership, and ensuring that the array lives at least as long as the `ModuloBuffer`/`BlocksRingBuffer`. `BlocksRingBuffer` can pass along these new options to its underlying `ModuloBuffer`. The main use will be for small on-stack `BlocksRingBuffer` that can store a stack trace, or to more easily collect data (without allocating anything on the heap) that can then go into the upcoming `ProfileBuffer`'s `BlocksRingBuffer`. Differential Revision: https://phabricator.services.mozilla.com/D38285
ab9dfd8e9360d3c4f01d7912e3928ed36e3641f7: Bug 1565137 - BlocksRingBuffer is a thread-safe variable-sized circular buffer - r=gregtatum
Gerald Squelart <gsquelart@mozilla.com> - Tue, 16 Jul 2019 07:57:24 +0000 - rev 546766
Push 2165 by ffxbld-merge at Mon, 14 Oct 2019 16:30:58 +0000
Bug 1565137 - BlocksRingBuffer is a thread-safe variable-sized circular buffer - r=gregtatum This adds to the byte-oriented ModuloBuffer from bug 1563425: - Thread-safety: All APIs may be called at any time from any thread. - Structure: The buffer will be divided in "blocks" of different size, with some block meta-data and space for the user "entry". - Capable of handling user resources: The user may provide a "deleter" that will be informed about soon-to-be-destroyed entries; so if some entries reference outside resources, these references may be properly released. Note: This first implementation still only allows the user to manipulate bytes and trivially-copyable objects (same as with the ModuloBuffer iterators). A follow-up bug will introduce better serialization capabilities, with the aim to eventually store everything that current Profiler Markers and their payloads contain. Differential Revision: https://phabricator.services.mozilla.com/D37702
3f48535246dbba6e12cc003a0031c32501e1ab1d: Bug 1563425 - ModuloBuffer is a basic circular byte buffer with iterator and LEB128 helpers - r=gregtatum
Gerald Squelart <gsquelart@mozilla.com> - Tue, 09 Jul 2019 04:46:19 +0000 - rev 545768
Push 2165 by ffxbld-merge at Mon, 14 Oct 2019 16:30:58 +0000
Bug 1563425 - ModuloBuffer is a basic circular byte buffer with iterator and LEB128 helpers - r=gregtatum Basic usage: - Create buffer: `ModuloBuffer mb(PowerOfTwo);` - Get iterator: `auto writer = mb.WriterAt(Index);` (or `ReaderAt()`) - Basic iterator functions on bytes: `*++writer = 'x';` - Write: `writer.WriteULEB128(sizeof(int)); writer.WriteObject<int>(42);` - Comparisons, move: `while (writer > reader) { --writer; }` - Read: `size_t s = reader.ReadULEB128<size_t>(); int i = ReadObject<int>();` There are no safety checks, it will be up to the caller to ensure thread-safety, and data safety when wrapping around the buffer. Differential Revision: https://phabricator.services.mozilla.com/D36869
50fa235ffdd07ae459ad5c6eba8e0f0fca53f597: Bug 1578354 - Remove the obsolete condition so that JS frames are now properly filtered in in the call tree. r=gregtatum, a=RyanVM
Julien Wajsberg <felash@gmail.com> - Thu, 05 Sep 2019 15:20:36 +0000 - rev 545305
Push 2146 by ryanvm@gmail.com at Tue, 17 Sep 2019 13:55:27 +0000
Bug 1578354 - Remove the obsolete condition so that JS frames are now properly filtered in in the call tree. r=gregtatum, a=RyanVM Bug 1557789 added categories to all JS frames, so as a result JS frames where all filtered out because of the condition removed in this patch. This condition is basically a premature optimization, removing it shouldn't bring any behavior difference. Differential Revision: https://phabricator.services.mozilla.com/D44803
41fb123dc5600d302dc2fa3b0e3eb1d79be12db3: Bug 1562606 - Implement unsigned LEB128 functions working over iterators - r=gregtatum
Gerald Squelart <gsquelart@mozilla.com> - Wed, 03 Jul 2019 14:49:10 +0000 - rev 544045
Push 2131 by ffxbld-merge at Mon, 26 Aug 2019 18:30:20 +0000
Bug 1562606 - Implement unsigned LEB128 functions working over iterators - r=gregtatum The new ProfileBuffer data structure will need to store block sizes (usually small, LEB128 uses fewer bytes for small numbers), and the circular buffer will provide iterators that hide the wrapping-around. Differential Revision: https://phabricator.services.mozilla.com/D36473
36f64a7df80cde6e66e84ac09c66df0c2ea1cf14: Bug 1561886 - Color the profiler icon in blue if the profiler is running at startup r=gregtatum
Julien Wajsberg <felash@gmail.com> - Fri, 28 Jun 2019 14:12:00 +0000 - rev 543382
Push 2131 by ffxbld-merge at Mon, 26 Aug 2019 18:30:20 +0000
Bug 1561886 - Color the profiler icon in blue if the profiler is running at startup r=gregtatum Differential Revision: https://phabricator.services.mozilla.com/D36198
4e287f4fe0298900384fed475a2e6f81734fcf26: Bug 1561875 - Increase the profiler's popup's width to fix layout issues on Linux r=gregtatum
Julien Wajsberg <felash@gmail.com> - Thu, 27 Jun 2019 23:01:47 +0000 - rev 543345
Push 2131 by ffxbld-merge at Mon, 26 Aug 2019 18:30:20 +0000
Bug 1561875 - Increase the profiler's popup's width to fix layout issues on Linux r=gregtatum Differential Revision: https://phabricator.services.mozilla.com/D36181
6f075fcdd821896ec9af08f65ca881a3c1dc524f: Bug 1552063 - Use PowerOfTwo and PowerOfTwoMask in profilers - r=gregtatum
Gerald Squelart <gsquelart@mozilla.com> - Fri, 28 Jun 2019 07:12:57 +0000 - rev 543320
Push 2131 by ffxbld-merge at Mon, 26 Aug 2019 18:30:20 +0000
Bug 1552063 - Use PowerOfTwo and PowerOfTwoMask in profilers - r=gregtatum PowerOfTwo makes for a cleaner and more expressive interface, showing that the profiler will use a power-of-2 storage size. Using PowerOfTwoMask in ProfilerBuffer also makes it more obvious that we want cheap modulo operations. And we don't need to keep the original capacity, as it's only used once and can easily be recomputed from the mask. Differential Revision: https://phabricator.services.mozilla.com/D36027
03db1aa367a2cfb3beca68cfcaecc1e1070108cd: Bug 1552063 - PowerOfTwo, PowerOfTwoMask - r=gregtatum
Gerald Squelart <gsquelart@mozilla.com> - Fri, 28 Jun 2019 07:12:54 +0000 - rev 543319
Push 2131 by ffxbld-merge at Mon, 26 Aug 2019 18:30:20 +0000
Bug 1552063 - PowerOfTwo, PowerOfTwoMask - r=gregtatum PowerOfTwo stores a power of 2 value, i.e., 2^N. PowerOfTwoMask stores a mask corresponding to a power of 2, i.e., 2^N-1. These should be used in places where a power of 2 (or its mask) is stored or expected. `% PowerOfTwo{,Mask}` and `& PowerOfTwoMask` operations are optimal. MakePowerOfTwo{,Mask}<T, Value>() may be used to create statically-checked constants. {,Make}PowerOfTwo{,Mask}{32,64} shortcuts for common 32- and 64-bit types. Differential Revision: https://phabricator.services.mozilla.com/D36026
2975f3f765763cf9d3f2f4064816db965792db0b: Bug 1552063 - Use PowerOfTwo and PowerOfTwoMask in profilers - r=gregtatum
Gerald Squelart <gsquelart@mozilla.com> - Thu, 27 Jun 2019 14:23:17 +0000 - rev 543290
Push 2131 by ffxbld-merge at Mon, 26 Aug 2019 18:30:20 +0000
Bug 1552063 - Use PowerOfTwo and PowerOfTwoMask in profilers - r=gregtatum PowerOfTwo makes for a cleaner and more expressive interface, showing that the profiler will use a power-of-2 storage size. Using PowerOfTwoMask in ProfilerBuffer also makes it more obvious that we want cheap modulo operations. And we don't need to keep the original capacity, as it's only used once and can easily be recomputed from the mask. Differential Revision: https://phabricator.services.mozilla.com/D36027
6284bcd7304ed3dd68157661254085245f2a7900: Bug 1552063 - PowerOfTwo, PowerOfTwoMask - r=gregtatum
Gerald Squelart <gsquelart@mozilla.com> - Thu, 27 Jun 2019 22:33:29 +0000 - rev 543289
Push 2131 by ffxbld-merge at Mon, 26 Aug 2019 18:30:20 +0000
Bug 1552063 - PowerOfTwo, PowerOfTwoMask - r=gregtatum PowerOfTwo stores a power of 2 value, i.e., 2^N. PowerOfTwoMask stores a mask corresponding to a power of 2, i.e., 2^N-1. These should be used in places where a power of 2 (or its mask) is stored or expected. `% PowerOfTwo{,Mask}` and `& PowerOfTwoMask` operations are optimal. MakePowerOfTwo{,Mask}<T, Value>() may be used to create statically-checked constants. {,Make}PowerOfTwo{,Mask}{32,64} shortcuts for common 32- and 64-bit types. Differential Revision: https://phabricator.services.mozilla.com/D36026
9d1bdc51c250e4e9618390f4f2b891fba1ab39bd: Bug 1550130 - make tools/profiler/tests/xpcshell/test_enterjit_osr.js more robust. r=gregtatum
Joel Maher <jmaher@mozilla.com> - Mon, 20 May 2019 18:15:24 +0000 - rev 537439
Push 2131 by ffxbld-merge at Mon, 26 Aug 2019 18:30:20 +0000
Bug 1550130 - make tools/profiler/tests/xpcshell/test_enterjit_osr.js more robust. r=gregtatum make tools/profiler/tests/xpcshell/test_enterjit_osr.js more robust. Differential Revision: https://phabricator.services.mozilla.com/D31796
a6acf6041262f553d5ca70fdfe764c29afbca4c6: Bug 1550130 - make tools/profiler/tests/xpcshell/test_enterjit_osr.js more robust. r=gregtatum a=test-only
Joel Maher <jmaher@mozilla.com> - Tue, 25 Jun 2019 13:39:19 -0400 - rev 537137
Push 2082 by ffxbld-merge at Mon, 01 Jul 2019 08:34:18 +0000
Bug 1550130 - make tools/profiler/tests/xpcshell/test_enterjit_osr.js more robust. r=gregtatum a=test-only Differential Revision: https://phabricator.services.mozilla.com/D31796
cb15b108719acd80d9c59b773a1838b9d4d6c7f1: Bug 1524982 - Use browser loader in performance panel to avoid blocking toolbox destroy;r=gregtatum,ochameau
Julian Descottes <jdescottes@mozilla.com> - Mon, 18 Feb 2019 16:37:18 +0000 - rev 520695
Push 2032 by ffxbld-merge at Mon, 13 May 2019 09:36:57 +0000
Bug 1524982 - Use browser loader in performance panel to avoid blocking toolbox destroy;r=gregtatum,ochameau The main goal is to use the browser loader instead of script tags to avoid using promises tied to the document during the panel's destroy. I tried to cleanup a bit the modules, to rely less on globals and more on explicit require calls, but there is room for improvement left. I will write an additional test to check that toolboxes in WINDOW hosts can be closed and reopened for any of our panels in a second changeset. Differential Revision: https://phabricator.services.mozilla.com/D19865
5a1d7bbc58cf3bc7daa18237ca67f02d905e5344: Bug 1525830 - DiskIOMarkerPayload::StreamPayload should output `mOperation` for the "operation" - r=gregtatum
Gerald Squelart <gsquelart@mozilla.com> - Thu, 07 Feb 2019 13:42:23 +0000 - rev 518494
Push 2032 by ffxbld-merge at Mon, 13 May 2019 09:36:57 +0000
Bug 1525830 - DiskIOMarkerPayload::StreamPayload should output `mOperation` for the "operation" - r=gregtatum mFilename is already present in "filename". Differential Revision: https://phabricator.services.mozilla.com/D18921
bed93ebb313b1fb65bfbce423c7c09ac277c26e9: Bug 1476775 - Part 2: Change the profiler usage in devtools after API change r=julienw,gregtatum
Nazım Can Altınova <canaltinova@gmail.com> - Fri, 23 Nov 2018 16:10:08 +0000 - rev 507145
Push 1905 by ffxbld-merge at Mon, 21 Jan 2019 12:33:13 +0000
Bug 1476775 - Part 2: Change the profiler usage in devtools after API change r=julienw,gregtatum Depends on D6267 Differential Revision: https://phabricator.services.mozilla.com/D6268
a14f9ec04145cc4d4cceeec942c44db12024c323: Bug 1457546 - Add checkbox to record screenshots in new performance pane r=gregtatum
Barret Rennie <barret@brennie.ca> - Tue, 20 Nov 2018 18:32:00 +0000 - rev 506643
Push 1905 by ffxbld-merge at Mon, 21 Jan 2019 12:33:13 +0000
Bug 1457546 - Add checkbox to record screenshots in new performance pane r=gregtatum Differential Revision: https://phabricator.services.mozilla.com/D12339
8355628364af21b89962a5b60fd9032bfead32f5: Bug 1465924 - Add profile.threads[i].processName which contains "Main Process", or the content process's name like "WebExtensions" - r=gregtatum
Gerald Squelart <gsquelart@mozilla.com> - Fri, 02 Nov 2018 21:52:32 +0000 - rev 503980
Push 1905 by ffxbld-merge at Mon, 21 Jan 2019 12:33:13 +0000
Bug 1465924 - Add profile.threads[i].processName which contains "Main Process", or the content process's name like "WebExtensions" - r=gregtatum This field is in addition to the existing process type fields we already have: - profile.threads[i].processType contains the string for the GeckoProcessType. - profile.threads[i].name contains the ThreadInfo name. Differential Revision: https://phabricator.services.mozilla.com/D10549
33b1c05d92a70b51b12f08484637f9999f2c9976: Bug 1489745 - reduce overhead of the performance test that also selects the memory r=gregtatum
Julien Wajsberg <felash@gmail.com> - Wed, 24 Oct 2018 12:09:45 +0000 - rev 501978
Push 1905 by ffxbld-merge at Mon, 21 Jan 2019 12:33:13 +0000
Bug 1489745 - reduce overhead of the performance test that also selects the memory r=gregtatum In this patch we use the previous change to reduce the overhead in the specific test that fails in ccov builds, by reducing the sample frequency. Depends on D8548 Differential Revision: https://phabricator.services.mozilla.com/D8435
3312d8b04ebda7ed5b25b72fff6d68fe7a92381a: Bug 1489745 - Reduce the buffer size for all tests r=gregtatum
Julien Wajsberg <felash@gmail.com> - Wed, 24 Oct 2018 12:09:35 +0000 - rev 501976
Push 1905 by ffxbld-merge at Mon, 21 Jan 2019 12:33:13 +0000
Bug 1489745 - Reduce the buffer size for all tests r=gregtatum We reduce the profiler's buffer size for all tests, to reduce the memory pressure and the overhead. This may fix some OOM intermittent crashes. Differential Revision: https://phabricator.services.mozilla.com/D8547
c05cdb233b60f923e667a9a6729e14e4a2dbbda0: Bug 1480593 - Allow setting a different instance of perf.html for the new performance panel, using a pref r=gregtatum
Julien Wajsberg <felash@gmail.com> - Thu, 18 Oct 2018 20:06:57 +0000 - rev 500658
Push 1864 by ffxbld-merge at Mon, 03 Dec 2018 15:51:40 +0000
Bug 1480593 - Allow setting a different instance of perf.html for the new performance panel, using a pref r=gregtatum Differential Revision: https://phabricator.services.mozilla.com/D8869