Use a common buffer in both Base and Gecko Profilers
Categories
(Core :: Gecko Profiler, task, P2)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox99 | --- | fixed |
People
(Reporter: mozbugz, Assigned: mozbugz)
References
(Blocks 1 open bug)
Details
(Whiteboard: [fp])
Attachments
(8 files)
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review |
Currently each profiler uses its own buffer, and when the Gecko Profiler (GP) starts while the Base Profiler (BP) is active, GP retrieves the full profile from BP and stops BP. This is quite expensive in memory and work.
Both profilers use the exact same serialization mechanism, so GP can read BP data straight from the buffer.
So the idea is to have only one buffer overall, initially created by BP, and then handed over to GP without any processing, and hopefully with minimal interruption.
This will also allow base markers to continue targeting the mozglue-visible common buffer, so they will be recorded even when BP has stopped (and GP is active).
| Assignee | ||
Comment 1•4 years ago
|
||
Depends on D137392
| Assignee | ||
Comment 2•4 years ago
|
||
Depends on D137800
| Assignee | ||
Comment 3•4 years ago
|
||
Note that they are still separate buffers for now.
Depends on D137801
| Assignee | ||
Comment 4•4 years ago
|
||
Depends on D137802
| Assignee | ||
Comment 5•4 years ago
|
||
Depends on D137803
| Assignee | ||
Comment 6•4 years ago
|
||
Depends on D137804
| Assignee | ||
Comment 7•4 years ago
|
||
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.
| Assignee | ||
Comment 8•4 years ago
|
||
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.
Depends on D138238
Comment 10•4 years ago
|
||
Backed out 8 changesets (Bug 1753192) for causing Gtest failures on GeckoProfiler.cpp.
Backout link
Push with failures
Failure Log
| Assignee | ||
Comment 11•4 years ago
|
||
I forgot to update a Gecko Profiler gtest to match the new behavior in https://phabricator.services.mozilla.com/D138239 , where a thread may now get its registration time from an earlier registration in the Base Profiler.
Comment 12•4 years ago
|
||
Comment 13•4 years ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/5f7c37c11c3a
https://hg.mozilla.org/mozilla-central/rev/88cdd3bb1df1
https://hg.mozilla.org/mozilla-central/rev/3747cc0c4b8e
https://hg.mozilla.org/mozilla-central/rev/4f575897b67f
https://hg.mozilla.org/mozilla-central/rev/bf1925f95330
https://hg.mozilla.org/mozilla-central/rev/506ef4b3a636
https://hg.mozilla.org/mozilla-central/rev/b60043138a22
https://hg.mozilla.org/mozilla-central/rev/c40948535daf
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 months ago
|
Updated•1 month ago
|
Description
•