Note that we can probably use mLastRefreshDriverTime directly in
DocumentTimeline::GetCurrentTimeStamp(), i.e. we don't need to use the refresh
driver there, but I'd preserve the current behavior.
Differential Revision: https://phabricator.services.mozilla.com/D97823
The next patch would have added yet another PROFILERxx_RAII macro, so it makes sense to gather them all into a single header file, to be #included where needed.
Differential Revision: https://phabricator.services.mozilla.com/D140169
This is a profiler-specific shared lock (aka readers-writer lock) implemented on top of RWLockImpl.
Similar to BaseProfilerMutex, it records which thread is currently holding the exclusive lock.
Differential Revision: https://phabricator.services.mozilla.com/D139916
This is a profiler-specific shared lock (aka readers-writer lock) implemented on top of RWLockImpl.
Similar to BaseProfilerMutex, it records which thread is currently holding the exclusive lock.
Differential Revision: https://phabricator.services.mozilla.com/D139916
This is consistent with how xpcom's Mutex has its platform-dependent code in mozglue, and will allow readers-writer locks in mozglue without duplication.
Differential Revision: https://phabricator.services.mozilla.com/D139669
Once the buffers are combined, some data could be stored in a thread before its registration with the Gecko Profiler.
Without this fix, the front-end would think the thread had not started yet, which could prevent interacting with that early data.
Differential Revision: https://phabricator.services.mozilla.com/D138239
Once the buffers are combined, a RequestedChunkRefCountedHolder could be referenced from the Base Profiler, which is invisible to the leak catcher; then handed over to the Gecko Profiler where it will eventually be dereferenced, which is logged with the leak catcher, resulting in an apparent negative leak.
This is fixed by keeping all (de)references secret.
Differential Revision: https://phabricator.services.mozilla.com/D138238
Once the buffers are combined, some data could be stored in a thread before its registration with the Gecko Profiler.
Without this fix, the front-end would think the thread had not started yet, which could prevent interacting with that early data.
Differential Revision: https://phabricator.services.mozilla.com/D138239
Once the buffers are combined, a RequestedChunkRefCountedHolder could be referenced from the Base Profiler, which is invisible to the leak catcher; then handed over to the Gecko Profiler where it will eventually be dereferenced, which is logged with the leak catcher, resulting in an apparent negative leak.
This is fixed by keeping all (de)references secret.
Differential Revision: https://phabricator.services.mozilla.com/D138238
With the latest Windows 10 SDK (10.0.20348.0), the value of NAN has changed
to differ from the STL. We intentionally #undef the value gotten from the SDK
and replace it with the STL value so that the comparison tests pass regardless
of the Windows SDK version.
Differential Revision: https://phabricator.services.mozilla.com/D137598
When trying to profile only one process, the profiler should not even start in those processes excluded by the filter, so that they don't use any resources (memory and CPU).
To do that, the filter is checked for "pid:" at the multiple locations it may appear:
- In the parent process, when starting the overall profiler, don't send the "Start" IPC to excluded processes.
- When a new process starts and initializes the profiler, don't start the profiler if the filter excludes this process.
- When a new process then registers itself with the parent, don't (re)start the profiler in excluded processes.
Child processes that don't run the profiler may still be asked for a JSON profile at the end of the profiling session. This is handled by sending an empty string, so that the parent process will correctly remove them from the pending-profile list.
Differential Revision: https://phabricator.services.mozilla.com/D135854
When trying to profile only one process, the profiler should not even start in those processes excluded by the filter, so that they don't use any resources (memory and CPU).
To do that, the filter is checked for "pid:" at the multiple locations it may appear:
- In the parent process, when starting the overall profiler, don't send the "Start" IPC to excluded processes.
- When a new process starts and initializes the profiler, don't start the profiler if the filter excludes this process.
- When a new process then registers itself with the parent, don't (re)start the profiler in excluded processes.
Child processes that don't run the profiler may still be asked for a JSON profile at the end of the profiling session. This is handled by sending an empty string, so that the parent process will correctly remove them from the pending-profile list.
Differential Revision: https://phabricator.services.mozilla.com/D135854
Cosmin Sabou
Nika Layzell
John Schanck
Hiroyuki Ikezoe
Emilio Cobos Álvarez
Serge Guelton
Norisz Fay
Randell Jesup
Cristian Tuns
Noemi Erli
Butkovits Atila
Mike Hommey
Gerald Squelart
smolnar
Alessio Placitelli
Marian-Vasile Laza
ahochheiden
Kris Wright
Iulian Moraru