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
Add `ProgressLogger` parameter to most JSON-generating functions.
Each function can update the given `ProgressLogger` between 0% and 100%, and create sub-loggers when calling functions.
The main goal of this instrumentation is to notice when any progress is made by child processes (when the parent process is gathering profiles), so it needs to go deep enough so that it is not stuck on a progress value for "too long" -- During development, that meant progress was always happening when observed every 10ms; In later patches, the overall timeout for no-progress-made will be at least 1 second.
Differential Revision: https://phabricator.services.mozilla.com/D135479
Class storing a value between 0 and 1, effectively 0% to 100%.
It will be used through a ProgressLogger object to track the progress of JSON profile generation (see following patches).
Differential Revision: https://phabricator.services.mozilla.com/D135477
Previously the process startup timestamp was computed lazily but this caused
some issues with some of our static analysis infra (see bug 1678152). This
moves computing the timestamp early during process startup and makes it happen
unconditionally.
Differential Revision: https://phabricator.services.mozilla.com/D136406
